Pagehandler Hijack v1.1

Release Notes

- fixes link urls in menu hooks

- fixes compatibility with other plugins that use the 'route', pagehandler hook

- moves settings form to *real* plugin settings page

  • got a strange issue here..
    i was seeing that all of the entity menu items (access and blog publish status etc) were being converted into urls.. they point to the site root.

    after disabling nearly every plugin, i found that it is pagehandler hijack that is adding the urls.

  • Fantastic, thanks to the author! I tried plenty of search, tried to change url by myself directly into plugins with page-handler, i tried htaccess rewriting, all haved differents problems,  before find your plugin which is definetly the one i needed, this is excellent for non-english elgg site!

  • One things remain hardly problematic on my case: When using page-handler with the event manager mod, map is called but don't show events points on the map.

    Is someone got an idea about this?

  • i just used this to change the path for the advanced statistics plugin which appears in the admin and although i can change the path, the change does not get used by elgg.. so presently i think this only works with non admin areas of elgg.. or is there something i have missed perhaps?

  • I never tested with 'admin', I'm not sure if it uses a standard pagehandler or not.  That was never an anticipated use case - any particular reason you want to rename that?

  • i don't strictly 'need' to rename that path (or any admin path) other than to make the admin areas easier to navigate for admins.

     

  • 'easier navigation' ? no need for anything fancy.. i use a simple comsolidated mouseover popup master menu for all admin menu stuff; so admin can get to his menu anytime anywhere, easily ;-P

    image

  • How would changing the 'admin' pagehandler to something else make navigation easier?  I'm lost as to what you are trying to achieve

  • the main use i have for pagehandler hijack is to make urls simpler and shorter, which allows them to be typed/copied/read more quickly and more easily remembered.

    i desired to change elggsite.com/admin/advanced_statistics/blah

    to: elggsite.com/admin/stats/blah

     

  • @ura - then you msunderstand what this plugin does.  The pagehandler in that example is 'admin'

  • eh? so your defining 'pagehandler' as '1st folder in url' ?

    the pagehandler hijack list includes all the relevant/possible url path extensions for plugins, including 'advanced_statistics' which co-relates to the admin/advanced_statistics/ path i quoted.
    so either pagehandlers are not '1st folder in url' or ur plugin has a bug in comparison to your intention, since 'advanced_statistics' appears in the pagehandler hijack list.

  • what is 'advanced_statistics' ? grep does not find this.

  • ohh lolz !
    that's external 3rd party plugin; not feature builtin @ core/admin
    so urls will not correlate ~ elggsite.com/advanced_statistics/blah 
    there's no embedded /admin in url for this plugin 
    .  pagehandler ~= advanced_statistics 
    .  page-parms [0] ~= blah 


  • My definition of the pagehandler is in fact, the definition of the pagehandler.  What you are seeing is a pagehandler that is defined by the advanced statistics plugin to serve as an ajax endpoint.  It has nothing to do with the admin display.

  • i just posted a question to the elgg google groups page as i am seeking to optimise my site and have used the services of newrelic.com to analyse what elgg is doing..

    i found that a major bottleneck appears to be being introduced by pagehandler_hijack (though i may be mis-reading the data) ..
    you can see the full details here:
    https://groups.google.com/forum/?hl=en&fromgroups#!topic/elgg-development/qdqEU2R3euw

  • the core pagehandler script calls almost every other function involved in generating the page, so I think you are misinterpreting the results (or the analyzing program is) and attributing it to the pagehandler functions.  No idea what the minify stuff is but it's not connected with this plugin, pagehandler_hijack doesn't do anything other than some rerouting magick.

  • that was what i thought..
    so i have written a support request at newrelic to find out why the hierarchy there is as it is. thanks

  • Matt, Had a look at your pagehandler hijack plugin in Elgg 1.9-dev. Needs a bit of a fix to make it work. 

    In your pagehandler_hijack_route function you set $returnvalue['handler'] = $original;

    However, you leave the $returnvalue['identifier'] set to the hijacked value.

    This results in a 404 Page not found error.

    If you set $returnvalue['identifier'] = $original; it works as expected.

  • Matt - Forgot one additional fix required for 1.9-dev. In the plugin's settings view you get the array of current handlers from $CONFIG which no longer works. I replaced that with

    //get current pagehandlers
    $handlers = array_keys(_elgg_services()->router->getPageHandlers());

    Not sure what the proper way of getting these is in 1.9 - but this works (though is not really kosher)

    Happen to know what the replacement for $CONFIG is in this case?

  • Thanks for testing this out - offhand I'm not sure what the best way to go about it is, most of my work thus far has been 1.8, and although I was invited into the core dev team I really haven't caught up on all of the changes that have happened for 1.9 yet.

  • Looking into this a bit - Elgg 1.9 does not provide a wrapper function for getting pagehandlers. It has elgg_register_page_handler and elgg_unregister_page_handler but not a public function nor a wrapper function to get an array of current registered handlers. This seems like an oversight to me...

    There is a public function in the Router.php class (public function getPageHandlers()) but no wrapper function in pagehandler.php in Elgg 1.9 lib. As a result I have resorted to calling the autoloader private function...

     _elgg_services()->router->getPageHandlers() 

  • @Jimmy, this is good feedback. To core and developers. @Core, look at providing a function to get registered page handlers.

    I just started with a vanilla 1.9 site, just to test current plugins. That was quite disappointing most plugins failed. So I decided to wait for a first release and than start upgrading my own plugins. From what I have seen from some other dev's, they seem to use the same tactic.

    That however will delay adoption of elgg 1.9 once it will be released, so maybe we should get more involved. Anyone has a suggestion on how to do this efficiently ?

    PS: (Sorry, getting of topic again, @admins you can move this to a new discussion if you want)

Matt Beckett

I'm a self-employed web developer, family man, nerd, scuba diver. Manager/maintainer of this elgg community site, and core Elgg development team member.

Stats

  • Category: Misc
  • License: GNU General Public License (GPL) version 2
  • Updated: 2015-3-22
  • Downloads: 1475
  • Recommendations: 16

Other Projects

View Matt Beckett's plugins