I am using 1.8.8. In index.php under main folder, there is a code snippet like this,
if (elgg_is_logged_in()) { forward('activity');
}
I think this code snippet will forward current user to Url "activity". My question is, I cannot find there is any php file called activity in the source tree. Any ideas?
> I think this code snippet will forward current user to Url "activity". My question is, I
> cannot find there is any php file called activity in the source tree. Any ideas?
Thanks for your reply. I am new to Elgg and I feel I like its simple style and extensible framework design and passion to write some plug-ins.
For my question, I searched the source tree, and there are multiple start.php files. Then I tried to search "activity" (which is the Url mapped to), but find no results.
Two more questions,
- appreciate if you could let me know what is the rule to find which start.php takes effect in my specific scenario/question? - could you help to point me where Url "activity" is mapped to an action? Sorry for that and I did investigation, but never found out as I am new to the code base.
On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
> On 11/10/12 10:25 AM, Lin Ma wrote: > > I think this code snippet will forward current user to Url "activity". > My question is, I > > cannot find there is any php file called activity in the source tree. > Any ideas?
> Most Elgg pages do not call PHP scripts directly. Most requests are > handled by > /engine/handlers/page_handler.php, which passes on control to the page > handling system > http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
Activity is part of the Elgg Core, it is not a plugin. It is registered within <ELGG-ROOT>/engine/lib/river.php line 643 It reads like this: elgg_register_page_handler('activity', 'elgg_river_page_handler');
As that is part of an *_init function, you can make an educated guess that it is loaded when engine starts. This is the line taking care of that: elgg_register_event_handler('init', 'system', 'elgg_river_init');
This is not an action, it is more of a page. Actions are different things in Elgg, those are mostly about being places when some from sends information to get something done. Se some of the start.php files within the plugins for examples, you are looking for elgg_register_action calls.
On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
> Hi Steve,
> Thanks for your reply. I am new to Elgg and I feel I like its simple style > and extensible framework design and passion to write some plug-ins.
> For my question, I searched the source tree, and there are multiple > start.php files. Then I tried to search "activity" (which is the Url mapped > to), but find no results.
> Two more questions,
> - appreciate if you could let me know what is the rule to find which > start.php takes effect in my specific scenario/question? > - could you help to point me where Url "activity" is mapped to an action? > Sorry for that and I did investigation, but never found out as I am new to > the code base.
> regards, > Lin
> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>> On 11/10/12 10:25 AM, Lin Ma wrote: >> > I think this code snippet will forward current user to Url "activity". >> My question is, I >> > cannot find there is any php file called activity in the source tree. >> Any ideas?
>> Most Elgg pages do not call PHP scripts directly. Most requests are >> handled by >> /engine/handlers/page_handler.php, which passes on control to the page >> handling system >> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
Thanks for the detailed reply. I have made some further study and have two more questions,
1. In Elgg's document for function "elgg_register_page_handle" => http://docs.elgg.org/wiki/Elgg_register_page_handler, the first parameter represents page type. My first question is how many page types are defined in Elgg, and what is the principle of defining page type (so that I can understand in the future what is the best practices to reuse or define new page type in the future); 2. I read through code of elgg_river_page_handler, I am totally lost about what happens when input is 'activity' for function call forward('activity') of index.php. I think elgg_river_page_handler is called, and input parameter is $page. And what is the value of $page when called from forward('activity') ofindex.php?
On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
> Activity is part of the Elgg Core, it is not a plugin. It is registered > within <ELGG-ROOT>/engine/lib/river.php line 643 > It reads like this: > elgg_register_page_handler('activity', 'elgg_river_page_handler');
> As that is part of an *_init function, you can make an educated guess that > it is loaded when engine starts. > This is the line taking care of that: > elgg_register_event_handler('init', 'system', 'elgg_river_init');
> This is not an action, it is more of a page. Actions are different things > in Elgg, those are mostly about being places when some from sends > information to get something done. Se some of the start.php files within > the plugins for examples, you are looking for elgg_register_action calls.
> Hope that helps.
> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>> Hi Steve,
>> Thanks for your reply. I am new to Elgg and I feel I like its simple >> style and extensible framework design and passion to write some plug-ins.
>> For my question, I searched the source tree, and there are multiple >> start.php files. Then I tried to search "activity" (which is the Url mapped >> to), but find no results.
>> Two more questions,
>> - appreciate if you could let me know what is the rule to find which >> start.php takes effect in my specific scenario/question? >> - could you help to point me where Url "activity" is mapped to an action? >> Sorry for that and I did investigation, but never found out as I am new to >> the code base.
>> regards, >> Lin
>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>> > I think this code snippet will forward current user to Url "activity". >>> My question is, I >>> > cannot find there is any php file called activity in the source tree. >>> Any ideas?
>>> Most Elgg pages do not call PHP scripts directly. Most requests are >>> handled by >>> /engine/handlers/page_handler.php, which passes on control to the page >>> handling system >>> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
When you hit this URL, elgg will attempt to call a registered page handler
for 'custom_handler' (e.g. a handler function registered with
elgg_register_page_handler('custom_handler', 'my_custom_handler_function'))
Elgg will call your my_custom_handler_function($segments, $handler); where
$segments is an array of segments in your url following your $handler =
'custom_handler'.
In case of activity, $segments are probably empty.
You can have as many handlers defined as you want. Just keep in mind that
handlers must be unique, or they might be overridden, depending on the
plugin priorities.
Perhaps, it would be best for you to seek help in the Elgg community.
On Mon, Nov 12, 2012 at 5:34 PM, Lin Ma <lin...@gmail.com> wrote:
> Hi Pjotr,
> Thanks for the detailed reply. I have made some further study and have two
> more questions,
> 1. In Elgg's document for function "elgg_register_page_handle" =>
> http://docs.elgg.org/wiki/Elgg_register_page_handler, the first parameter
> represents page type.
> My first question is how many page types are defined in Elgg, and what is
> the principle of defining page type (so that I can understand in the future
> what is the best
> practices to reuse or define new page type in the future);
> 2. I read through code of elgg_river_page_handler, I am totally lost about
> what happens when input is 'activity' for function call forward('activity')
> of index.php.
> I think elgg_river_page_handler is called, and input parameter is $page.
> And what is the value of $page when called from forward('activity') ofindex.php?
> regards,
> Lin
> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>> Activity is part of the Elgg Core, it is not a plugin. It is registered
>> within <ELGG-ROOT>/engine/lib/river.**php line 643
>> It reads like this:
>> elgg_register_page_handler('**activity', 'elgg_river_page_handler');
>> As that is part of an *_init function, you can make an educated guess
>> that it is loaded when engine starts.
>> This is the line taking care of that:
>> elgg_register_event_handler('**init', 'system', 'elgg_river_init');
>> This is not an action, it is more of a page. Actions are different things
>> in Elgg, those are mostly about being places when some from sends
>> information to get something done. Se some of the start.php files within
>> the plugins for examples, you are looking for elgg_register_action calls.
>> Hope that helps.
>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>> Hi Steve,
>>> Thanks for your reply. I am new to Elgg and I feel I like its simple
>>> style and extensible framework design and passion to write some plug-ins.
>>> For my question, I searched the source tree, and there are multiple
>>> start.php files. Then I tried to search "activity" (which is the Url mapped
>>> to), but find no results.
>>> Two more questions,
>>> - appreciate if you could let me know what is the rule to find which
>>> start.php takes effect in my specific scenario/question?
>>> - could you help to point me where Url "activity" is mapped to an
>>> action? Sorry for that and I did investigation, but never found out as I am
>>> new to the code base.
>>> regards,
>>> Lin
>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>> On 11/10/12 10:25 AM, Lin Ma wrote:
>>>> > I think this code snippet will forward current user to Url
>>>> "activity". My question is, I
>>>> > cannot find there is any php file called activity in the source tree.
>>>> Any ideas?
>>> --
> You received this message because you are subscribed to the Google
> Groups "Elgg development" group.
> To post to this group, send email to elgg-development@googlegroups.com
> To unsubscribe from this group, send email to
> elgg-development+unsubscribe@googlegroups.com
*"Hope is a state of mind, not of the world. Hope, in this deep and
powerful sense, is not the same as joy that things are going well, or
willingness to invest in enterprises that are obviously heading for
success, but rather an ability to work for something because it is good"* -
Vaclav Havel
Hmm .... the first parameter is the name of the handler to be used, it is not about type (as it has been noted already). This is a string representation that you will see within the URL. As mentioned it should be unique. I guess that the best strategy would be to use the name of the plugin (as every plugin has a unique name anyway due to being a directory), this seems like a good way to go. It looks like Core plugins do tend to follow that logic.
Call to function forward('activity') does one thing - issues a header redirect to an address (it also does some magic). Simply put - it will see that something provided is not a URL, so it takes BASE_URL and adds 'activity' to that and redirects your browser there, the result is something like that: http://your.base.url/activity
The logic of the index is easy, if the user is a logged in one (non-anonymous) then there is not point in showing the index page, it just redirects the users to activity page/pages, the system understands that this is mapped to a handler (as it was registered): the logic http://your.base.url/<HANDLER>/
So the first element after BASE_URL is the handler. That handler is mapped to some function.
The $page is an array of whatever comes after the <HANDLER> part of the URL, the easy explanation would be to take the string and explode that using slash; something like explode("/", "first/second/third"). In reality it is a bit more complex than that.
So, the elgg_river_page_handler function does pretty-much something like that: Sets page owner to be currently logged in user. Call to elgg_extract takes the values of key 0 of an array, if that is not there 'all' will be used as the default. Does a bit more magic and checking, set_input pushes page_type to be available to the script being included next. Loads "pages/river.php" starting from the Elgg install path. Returns "true" telling that everything is handled and that is it.
If you open the <ELGG_ROOT>/pages/river.php file. You will see options being examined and page being constructed. Function elgg_list_river calls in the listing you see on the page. The rest of those call in sidebars, filters and other elements.
And last example might be now easy to understand: a URL like <BASE_URL>/things/view/1
Let us make a guess that there is a function things_page_handler that is registered to that page (the page it not a script, but just a string mapped to some handler - mo handler, no page; 404 response code).
So, getting to the point: $page will be:
array( 0 => 'view', 1 => 1 );
You can see the logic how things are mapped.
Hope that helps understad how things work. My explanations are a bit chaotic and I tend to skip some things and exhibit jumpy logic; but I did mu best.
On Monday, November 12, 2012 6:34:17 PM UTC+2, Lin Ma wrote:
> Hi Pjotr,
> Thanks for the detailed reply. I have made some further study and have two > more questions,
> 1. In Elgg's document for function "elgg_register_page_handle" => > http://docs.elgg.org/wiki/Elgg_register_page_handler, the first parameter > represents page type. > My first question is how many page types are defined in Elgg, and what is > the principle of defining page type (so that I can understand in the future > what is the best > practices to reuse or define new page type in the future); > 2. I read through code of elgg_river_page_handler, I am totally lost about > what happens when input is 'activity' for function call forward('activity') > of index.php. > I think elgg_river_page_handler is called, and input parameter is $page. > And what is the value of $page when called from forward('activity') ofindex.php?
> regards, > Lin
> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>> Activity is part of the Elgg Core, it is not a plugin. It is registered >> within <ELGG-ROOT>/engine/lib/river.php line 643 >> It reads like this: >> elgg_register_page_handler('activity', 'elgg_river_page_handler');
>> As that is part of an *_init function, you can make an educated guess >> that it is loaded when engine starts. >> This is the line taking care of that: >> elgg_register_event_handler('init', 'system', 'elgg_river_init');
>> This is not an action, it is more of a page. Actions are different things >> in Elgg, those are mostly about being places when some from sends >> information to get something done. Se some of the start.php files within >> the plugins for examples, you are looking for elgg_register_action calls.
>> Hope that helps.
>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>> Hi Steve,
>>> Thanks for your reply. I am new to Elgg and I feel I like its simple >>> style and extensible framework design and passion to write some plug-ins.
>>> For my question, I searched the source tree, and there are multiple >>> start.php files. Then I tried to search "activity" (which is the Url mapped >>> to), but find no results.
>>> Two more questions,
>>> - appreciate if you could let me know what is the rule to find which >>> start.php takes effect in my specific scenario/question? >>> - could you help to point me where Url "activity" is mapped to an >>> action? Sorry for that and I did investigation, but never found out as I am >>> new to the code base.
>>> regards, >>> Lin
>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>>> > I think this code snippet will forward current user to Url >>>> "activity". My question is, I >>>> > cannot find there is any php file called activity in the source tree. >>>> Any ideas?
>>>> Most Elgg pages do not call PHP scripts directly. Most requests are >>>> handled by >>>> /engine/handlers/page_handler.php, which passes on control to the page >>>> handling system >>>> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
I highly recommend setting up xdebug remote debugging and stepping through the code. It's a pain to set up the first time, but you'll get a much better sense of what is happening.
My question is when forward ('activity'') is called, I think function elgg_river_page_handler (in lib/engine/river.php) is called, I am confused about what it is doing internally in the function. More details about my confusion, from UI perspective, I think the main dashboard should be displayed for that user, but from the code in elgg_river_page_handler (in lib/engine/river.php), I cannot see any code responsible for displaying friends list, group information, etc. Appreciate if you could help to clarify.
> When you hit this URL, elgg will attempt to call a registered page handler > for 'custom_handler' (e.g. a handler function registered with > elgg_register_page_handler('custom_handler', 'my_custom_handler_function'))
> Elgg will call your my_custom_handler_function($segments, $handler); where > $segments is an array of segments in your url following your $handler = > 'custom_handler'.
> In case of activity, $segments are probably empty.
> You can have as many handlers defined as you want. Just keep in mind that > handlers must be unique, or they might be overridden, depending on the > plugin priorities.
> Perhaps, it would be best for you to seek help in the Elgg community.
> On Mon, Nov 12, 2012 at 5:34 PM, Lin Ma <lin...@gmail.com <javascript:>>wrote:
>> Hi Pjotr,
>> Thanks for the detailed reply. I have made some further study and have >> two more questions,
>> 1. In Elgg's document for function "elgg_register_page_handle" => >> http://docs.elgg.org/wiki/Elgg_register_page_handler, the first >> parameter represents page type. >> My first question is how many page types are defined in Elgg, and what is >> the principle of defining page type (so that I can understand in the future >> what is the best >> practices to reuse or define new page type in the future); >> 2. I read through code of elgg_river_page_handler, I am totally lost >> about what happens when input is 'activity' for function call >> forward('activity') of index.php. >> I think elgg_river_page_handler is called, and input parameter is $page. >> And what is the value of $page when called from forward('activity') ofindex.php?
>> regards, >> Lin
>> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>>> Activity is part of the Elgg Core, it is not a plugin. It is registered >>> within <ELGG-ROOT>/engine/lib/river.**php line 643 >>> It reads like this: >>> elgg_register_page_handler('**activity', 'elgg_river_page_handler');
>>> As that is part of an *_init function, you can make an educated guess >>> that it is loaded when engine starts. >>> This is the line taking care of that: >>> elgg_register_event_handler('**init', 'system', 'elgg_river_init');
>>> This is not an action, it is more of a page. Actions are different >>> things in Elgg, those are mostly about being places when some from sends >>> information to get something done. Se some of the start.php files within >>> the plugins for examples, you are looking for elgg_register_action calls.
>>> Hope that helps.
>>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>>> Hi Steve,
>>>> Thanks for your reply. I am new to Elgg and I feel I like its simple >>>> style and extensible framework design and passion to write some plug-ins.
>>>> For my question, I searched the source tree, and there are multiple >>>> start.php files. Then I tried to search "activity" (which is the Url mapped >>>> to), but find no results.
>>>> Two more questions,
>>>> - appreciate if you could let me know what is the rule to find which >>>> start.php takes effect in my specific scenario/question? >>>> - could you help to point me where Url "activity" is mapped to an >>>> action? Sorry for that and I did investigation, but never found out as I am >>>> new to the code base.
>>>> regards, >>>> Lin
>>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>>>> > I think this code snippet will forward current user to Url >>>>> "activity". My question is, I >>>>> > cannot find there is any php file called activity in the source >>>>> tree. Any ideas?
>>>> -- >> You received this message because you are subscribed to the Google >> Groups "Elgg development" group. >> To post to this group, send email to elgg-dev...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> elgg-developme...@googlegroups.com <javascript:>
> *"Hope is a state of mind, not of the world. Hope, in this deep and > powerful sense, is not the same as joy that things are going well, or > willingness to invest in enterprises that are obviously heading for > success, but rather an ability to work for something because it is good"* - > Vaclav Havel
Thanks for taking so much time to reply my question, Pjotr! Your reply is really excellent and in-depth. Actually not jumpy, well organized. :-)
I studied code and most confusions are gone, one confusion left, I think function "elgg_list_river" needs to be called in order to display a logged-in user main page. But I do not see it is invoked in function elgg_river_page_handler (I thought elgg_list_river should be called from elgg_river_page_handler, when forward('activity') triggers elgg_river_page_handler). Any comments?
On Tuesday, November 13, 2012 3:37:55 AM UTC+8, Pjotr wrote:
> Hmm .... the first parameter is the name of the handler to be used, it is > not about type (as it has been noted already). This is a string > representation that you will see within the URL. As mentioned it should be > unique. I guess that the best strategy would be to use the name of the > plugin (as every plugin has a unique name anyway due to being a directory), > this seems like a good way to go. It looks like Core plugins do tend to > follow that logic.
> Call to function forward('activity') does one thing - issues a header > redirect to an address (it also does some magic). Simply put - it will see > that something provided is not a URL, so it takes BASE_URL and adds > 'activity' to that and redirects your browser there, the result is > something like that: http://your.base.url/activity
> The logic of the index is easy, if the user is a logged in one > (non-anonymous) then there is not point in showing the index page, it just > redirects the users to activity page/pages, the system understands that > this is mapped to a handler (as it was registered): the logic > http://your.base.url/<HANDLER>/
> So the first element after BASE_URL is the handler. That handler is mapped > to some function.
> The $page is an array of whatever comes after the <HANDLER> part of the > URL, the easy explanation would be to take the string and explode that > using slash; something like explode("/", "first/second/third"). In reality > it is a bit more complex than that.
> So, the elgg_river_page_handler function does pretty-much something like > that: > Sets page owner to be currently logged in user. Call to elgg_extract takes > the values of key 0 of an array, if that is not there 'all' will be used as > the default. Does a bit more magic and checking, set_input pushes page_type > to be available to the script being included next. Loads "pages/river.php" > starting from the Elgg install path. Returns "true" telling that everything > is handled and that is it.
> If you open the <ELGG_ROOT>/pages/river.php file. You will see options > being examined and page being constructed. Function elgg_list_river calls > in the listing you see on the page. The rest of those call in sidebars, > filters and other elements.
> And last example might be now easy to understand: a URL like > <BASE_URL>/things/view/1
> Let us make a guess that there is a function things_page_handler that is > registered to that page (the page it not a script, but just a string mapped > to some handler - mo handler, no page; 404 response code).
> So, getting to the point: $page will be:
> array( > 0 => 'view', > 1 => 1 > );
> You can see the logic how things are mapped.
> Hope that helps understad how things work. My explanations are a bit > chaotic and I tend to skip some things and exhibit jumpy logic; but I did > mu best.
> Pjotr
> On Monday, November 12, 2012 6:34:17 PM UTC+2, Lin Ma wrote:
>> Hi Pjotr,
>> Thanks for the detailed reply. I have made some further study and have >> two more questions,
>> 1. In Elgg's document for function "elgg_register_page_handle" => >> http://docs.elgg.org/wiki/Elgg_register_page_handler, the first >> parameter represents page type. >> My first question is how many page types are defined in Elgg, and what is >> the principle of defining page type (so that I can understand in the future >> what is the best >> practices to reuse or define new page type in the future); >> 2. I read through code of elgg_river_page_handler, I am totally lost >> about what happens when input is 'activity' for function call >> forward('activity') of index.php. >> I think elgg_river_page_handler is called, and input parameter is $page. >> And what is the value of $page when called from forward('activity') ofindex.php?
>> regards, >> Lin
>> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>>> Activity is part of the Elgg Core, it is not a plugin. It is registered >>> within <ELGG-ROOT>/engine/lib/river.php line 643 >>> It reads like this: >>> elgg_register_page_handler('activity', 'elgg_river_page_handler');
>>> As that is part of an *_init function, you can make an educated guess >>> that it is loaded when engine starts. >>> This is the line taking care of that: >>> elgg_register_event_handler('init', 'system', 'elgg_river_init');
>>> This is not an action, it is more of a page. Actions are different >>> things in Elgg, those are mostly about being places when some from sends >>> information to get something done. Se some of the start.php files within >>> the plugins for examples, you are looking for elgg_register_action calls.
>>> Hope that helps.
>>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>>> Hi Steve,
>>>> Thanks for your reply. I am new to Elgg and I feel I like its simple >>>> style and extensible framework design and passion to write some plug-ins.
>>>> For my question, I searched the source tree, and there are multiple >>>> start.php files. Then I tried to search "activity" (which is the Url mapped >>>> to), but find no results.
>>>> Two more questions,
>>>> - appreciate if you could let me know what is the rule to find which >>>> start.php takes effect in my specific scenario/question? >>>> - could you help to point me where Url "activity" is mapped to an >>>> action? Sorry for that and I did investigation, but never found out as I am >>>> new to the code base.
>>>> regards, >>>> Lin
>>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>>>> > I think this code snippet will forward current user to Url >>>>> "activity". My question is, I >>>>> > cannot find there is any php file called activity in the source >>>>> tree. Any ideas?
>>>>> Most Elgg pages do not call PHP scripts directly. Most requests are >>>>> handled by >>>>> /engine/handlers/page_handler.php, which passes on control to the page >>>>> handling system >>>>> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
On Tuesday, November 13, 2012 6:22:14 AM UTC+8, Steve Clay wrote:
> On 11/12/12 11:34 AM, Lin Ma wrote: > > I thinkelgg_river_page_handler is called, and input parameter is $page. > And what is the > > value of $page ...
> $page receives an array of the URL segments after "/activity/". E.g.
> I highly recommend setting up xdebug remote debugging and stepping through > the code. It's > a pain to set up the first time, but you'll get a much better sense of > what is happening.
This last confusion is easily solved, elgg_list_river does get called. Just look at the line before the "return true;". It issues a require_once on <ELGG_ROOT_PATH>/pages/river.php, this will look for that file and include its contents to the current function (this is the simplest explanation of the idea).
If you look in there, there is a call to elgg_list_river on line 42. It is given the options determined by the code above. This means that elgg_river_page_handler does indeed run the function. It does add some more views, uses "content" layout and outputs the page.
On Tuesday, November 13, 2012 5:59:16 PM UTC+2, Lin Ma wrote:
> Thanks for taking so much time to reply my question, Pjotr! Your reply is > really excellent and in-depth. Actually not jumpy, well organized. :-)
> I studied code and most confusions are gone, one confusion left, I think > function "elgg_list_river" needs to be called in order to display a > logged-in user main page. But I do not see it is invoked in function > elgg_river_page_handler (I thought elgg_list_river should be called from > elgg_river_page_handler, when forward('activity') triggers > elgg_river_page_handler). Any comments?
> regards, > Lin
> On Tuesday, November 13, 2012 3:37:55 AM UTC+8, Pjotr wrote:
>> Hmm .... the first parameter is the name of the handler to be used, it is >> not about type (as it has been noted already). This is a string >> representation that you will see within the URL. As mentioned it should be >> unique. I guess that the best strategy would be to use the name of the >> plugin (as every plugin has a unique name anyway due to being a directory), >> this seems like a good way to go. It looks like Core plugins do tend to >> follow that logic.
>> Call to function forward('activity') does one thing - issues a header >> redirect to an address (it also does some magic). Simply put - it will see >> that something provided is not a URL, so it takes BASE_URL and adds >> 'activity' to that and redirects your browser there, the result is >> something like that: http://your.base.url/activity
>> The logic of the index is easy, if the user is a logged in one >> (non-anonymous) then there is not point in showing the index page, it just >> redirects the users to activity page/pages, the system understands that >> this is mapped to a handler (as it was registered): the logic >> http://your.base.url/<HANDLER>/
>> So the first element after BASE_URL is the handler. That handler is >> mapped to some function.
>> The $page is an array of whatever comes after the <HANDLER> part of the >> URL, the easy explanation would be to take the string and explode that >> using slash; something like explode("/", "first/second/third"). In reality >> it is a bit more complex than that.
>> So, the elgg_river_page_handler function does pretty-much something like >> that: >> Sets page owner to be currently logged in user. Call to elgg_extract >> takes the values of key 0 of an array, if that is not there 'all' will be >> used as the default. Does a bit more magic and checking, set_input pushes >> page_type to be available to the script being included next. Loads >> "pages/river.php" starting from the Elgg install path. Returns "true" >> telling that everything is handled and that is it.
>> If you open the <ELGG_ROOT>/pages/river.php file. You will see options >> being examined and page being constructed. Function elgg_list_river calls >> in the listing you see on the page. The rest of those call in sidebars, >> filters and other elements.
>> And last example might be now easy to understand: a URL like >> <BASE_URL>/things/view/1
>> Let us make a guess that there is a function things_page_handler that is >> registered to that page (the page it not a script, but just a string mapped >> to some handler - mo handler, no page; 404 response code).
>> So, getting to the point: $page will be:
>> array( >> 0 => 'view', >> 1 => 1 >> );
>> You can see the logic how things are mapped.
>> Hope that helps understad how things work. My explanations are a bit >> chaotic and I tend to skip some things and exhibit jumpy logic; but I did >> mu best.
>> Pjotr
>> On Monday, November 12, 2012 6:34:17 PM UTC+2, Lin Ma wrote:
>>> Hi Pjotr,
>>> Thanks for the detailed reply. I have made some further study and have >>> two more questions,
>>> 1. In Elgg's document for function "elgg_register_page_handle" => >>> http://docs.elgg.org/wiki/Elgg_register_page_handler, the first >>> parameter represents page type. >>> My first question is how many page types are defined in Elgg, and what >>> is the principle of defining page type (so that I can understand in the >>> future what is the best >>> practices to reuse or define new page type in the future); >>> 2. I read through code of elgg_river_page_handler, I am totally lost >>> about what happens when input is 'activity' for function call >>> forward('activity') of index.php. >>> I think elgg_river_page_handler is called, and input parameter is >>> $page. And what is the value of $page when called from forward('activity') >>> of index.php?
>>> regards, >>> Lin
>>> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>>>> Activity is part of the Elgg Core, it is not a plugin. It is registered >>>> within <ELGG-ROOT>/engine/lib/river.php line 643 >>>> It reads like this: >>>> elgg_register_page_handler('activity', 'elgg_river_page_handler');
>>>> As that is part of an *_init function, you can make an educated guess >>>> that it is loaded when engine starts. >>>> This is the line taking care of that: >>>> elgg_register_event_handler('init', 'system', 'elgg_river_init');
>>>> This is not an action, it is more of a page. Actions are different >>>> things in Elgg, those are mostly about being places when some from sends >>>> information to get something done. Se some of the start.php files within >>>> the plugins for examples, you are looking for elgg_register_action calls.
>>>> Hope that helps.
>>>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>>>> Hi Steve,
>>>>> Thanks for your reply. I am new to Elgg and I feel I like its simple >>>>> style and extensible framework design and passion to write some plug-ins.
>>>>> For my question, I searched the source tree, and there are multiple >>>>> start.php files. Then I tried to search "activity" (which is the Url mapped >>>>> to), but find no results.
>>>>> Two more questions,
>>>>> - appreciate if you could let me know what is the rule to find which >>>>> start.php takes effect in my specific scenario/question? >>>>> - could you help to point me where Url "activity" is mapped to an >>>>> action? Sorry for that and I did investigation, but never found out as I am >>>>> new to the code base.
>>>>> regards, >>>>> Lin
>>>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>>>>> > I think this code snippet will forward current user to Url >>>>>> "activity". My question is, I >>>>>> > cannot find there is any php file called activity in the source >>>>>> tree. Any ideas?
>>>>>> Most Elgg pages do not call PHP scripts directly. Most requests are >>>>>> handled by >>>>>> /engine/handlers/page_handler.php, which passes on control to the >>>>>> page handling system >>>>>> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
On Wednesday, November 14, 2012 4:13:19 PM UTC+8, Pjotr wrote:
> This last confusion is easily solved, elgg_list_river does get called. > Just look at the line before the "return true;". It issues a require_once > on <ELGG_ROOT_PATH>/pages/river.php, this will look for that file and > include its contents to the current function (this is the simplest > explanation of the idea).
> If you look in there, there is a call to elgg_list_river on line 42. It is > given the options determined by the code above. This means that > elgg_river_page_handler does indeed run the function. It does add some more > views, uses "content" layout and outputs the page.
> Hope that clears things out, > Pjotr
> On Tuesday, November 13, 2012 5:59:16 PM UTC+2, Lin Ma wrote:
>> Thanks for taking so much time to reply my question, Pjotr! Your reply is >> really excellent and in-depth. Actually not jumpy, well organized. :-)
>> I studied code and most confusions are gone, one confusion left, I think >> function "elgg_list_river" needs to be called in order to display a >> logged-in user main page. But I do not see it is invoked in function >> elgg_river_page_handler (I thought elgg_list_river should be called from >> elgg_river_page_handler, when forward('activity') triggers >> elgg_river_page_handler). Any comments?
>> regards, >> Lin
>> On Tuesday, November 13, 2012 3:37:55 AM UTC+8, Pjotr wrote:
>>> Hmm .... the first parameter is the name of the handler to be used, it >>> is not about type (as it has been noted already). This is a string >>> representation that you will see within the URL. As mentioned it should be >>> unique. I guess that the best strategy would be to use the name of the >>> plugin (as every plugin has a unique name anyway due to being a directory), >>> this seems like a good way to go. It looks like Core plugins do tend to >>> follow that logic.
>>> Call to function forward('activity') does one thing - issues a header >>> redirect to an address (it also does some magic). Simply put - it will see >>> that something provided is not a URL, so it takes BASE_URL and adds >>> 'activity' to that and redirects your browser there, the result is >>> something like that: http://your.base.url/activity
>>> The logic of the index is easy, if the user is a logged in one >>> (non-anonymous) then there is not point in showing the index page, it just >>> redirects the users to activity page/pages, the system understands that >>> this is mapped to a handler (as it was registered): the logic >>> http://your.base.url/<HANDLER>/
>>> So the first element after BASE_URL is the handler. That handler is >>> mapped to some function.
>>> The $page is an array of whatever comes after the <HANDLER> part of the >>> URL, the easy explanation would be to take the string and explode that >>> using slash; something like explode("/", "first/second/third"). In reality >>> it is a bit more complex than that.
>>> So, the elgg_river_page_handler function does pretty-much something like >>> that: >>> Sets page owner to be currently logged in user. Call to elgg_extract >>> takes the values of key 0 of an array, if that is not there 'all' will be >>> used as the default. Does a bit more magic and checking, set_input pushes >>> page_type to be available to the script being included next. Loads >>> "pages/river.php" starting from the Elgg install path. Returns "true" >>> telling that everything is handled and that is it.
>>> If you open the <ELGG_ROOT>/pages/river.php file. You will see options >>> being examined and page being constructed. Function elgg_list_river calls >>> in the listing you see on the page. The rest of those call in sidebars, >>> filters and other elements.
>>> And last example might be now easy to understand: a URL like >>> <BASE_URL>/things/view/1
>>> Let us make a guess that there is a function things_page_handler that is >>> registered to that page (the page it not a script, but just a string mapped >>> to some handler - mo handler, no page; 404 response code).
>>> So, getting to the point: $page will be:
>>> array( >>> 0 => 'view', >>> 1 => 1 >>> );
>>> You can see the logic how things are mapped.
>>> Hope that helps understad how things work. My explanations are a bit >>> chaotic and I tend to skip some things and exhibit jumpy logic; but I did >>> mu best.
>>> Pjotr
>>> On Monday, November 12, 2012 6:34:17 PM UTC+2, Lin Ma wrote:
>>>> Hi Pjotr,
>>>> Thanks for the detailed reply. I have made some further study and have >>>> two more questions,
>>>> 1. In Elgg's document for function "elgg_register_page_handle" => >>>> http://docs.elgg.org/wiki/Elgg_register_page_handler, the first >>>> parameter represents page type. >>>> My first question is how many page types are defined in Elgg, and what >>>> is the principle of defining page type (so that I can understand in the >>>> future what is the best >>>> practices to reuse or define new page type in the future); >>>> 2. I read through code of elgg_river_page_handler, I am totally lost >>>> about what happens when input is 'activity' for function call >>>> forward('activity') of index.php. >>>> I think elgg_river_page_handler is called, and input parameter is >>>> $page. And what is the value of $page when called from forward('activity') >>>> of index.php?
>>>> regards, >>>> Lin
>>>> On Sunday, November 11, 2012 4:21:36 PM UTC+8, Pjotr wrote:
>>>>> Activity is part of the Elgg Core, it is not a plugin. It is >>>>> registered within <ELGG-ROOT>/engine/lib/river.php line 643 >>>>> It reads like this: >>>>> elgg_register_page_handler('activity', 'elgg_river_page_handler');
>>>>> As that is part of an *_init function, you can make an educated guess >>>>> that it is loaded when engine starts. >>>>> This is the line taking care of that: >>>>> elgg_register_event_handler('init', 'system', 'elgg_river_init');
>>>>> This is not an action, it is more of a page. Actions are different >>>>> things in Elgg, those are mostly about being places when some from sends >>>>> information to get something done. Se some of the start.php files within >>>>> the plugins for examples, you are looking for elgg_register_action calls.
>>>>> Hope that helps.
>>>>> On Sunday, November 11, 2012 10:10:42 AM UTC+2, Lin Ma wrote:
>>>>>> Hi Steve,
>>>>>> Thanks for your reply. I am new to Elgg and I feel I like its simple >>>>>> style and extensible framework design and passion to write some plug-ins.
>>>>>> For my question, I searched the source tree, and there are multiple >>>>>> start.php files. Then I tried to search "activity" (which is the Url mapped >>>>>> to), but find no results.
>>>>>> Two more questions,
>>>>>> - appreciate if you could let me know what is the rule to find which >>>>>> start.php takes effect in my specific scenario/question? >>>>>> - could you help to point me where Url "activity" is mapped to an >>>>>> action? Sorry for that and I did investigation, but never found out as I am >>>>>> new to the code base.
>>>>>> regards, >>>>>> Lin
>>>>>> On Sunday, November 11, 2012 2:06:07 AM UTC+8, Steve Clay wrote:
>>>>>>> On 11/10/12 10:25 AM, Lin Ma wrote: >>>>>>> > I think this code snippet will forward current user to Url >>>>>>> "activity". My question is, I >>>>>>> > cannot find there is any php file called activity in the source >>>>>>> tree. Any ideas?
>>>>>>> Most Elgg pages do not call PHP scripts directly. Most requests are >>>>>>> handled by >>>>>>> /engine/handlers/page_handler.php, which passes on control to the >>>>>>> page handling system >>>>>>> http://docs.elgg.org/wiki/Engine/Controllers/PageHandler
