pg and mod directories

I am trying to gain an understanding of the mod and pg directories,  I would like to make them consisistent across the site, for example I would like to elimintate "mod" from the url by replacing the variants that occur between mod and pg pages, with pages that will display under the "pg" directory.

 

  • I would like to make them consisistent across the site

    You and me both :) 

    The difference is that some of the plugins use page handlers (the 'pg' ones) while others call the PHP files directly (the 'mod' ones).  The preferred way is the use of page handlers.  For Elgg's official plugins, we will sort this out for 1.8.  3rd party plugins will need to be updated by their authors.

    To make them consistent, you will have to have a good grasp of PHP and Elgg's framework.  Then, it's simply a matter of converting direct calls to the page handlers instead.

  • I started to realize the diffrences in the last hour or so, and noe looking into registering page handelers, I think what i see is that the handeler simply breaks the url down to an array, then I would want to build a switch case or if, to then include the file I want into the index page, making the index page the handeler?  am I missing any complexities?

  • Thanks Brett,  Props to the core!

  • Nope...that's all the pagehandler does.

  • I'm glad that in 1.8 we will have explicit "mod" URLs cleaned up.  What about action scripts?  It's perhaps even more important than page handlers.  If I register a plugin handler to do some pre-processing for an action, it won't be executed if the action PHP script is invoked explicitly in the URL.  I would go so far as suggesting that .htaccess should have a rewrite rule to redirect action/**/*.php and actions/**/*.php to an error page.

  • Actions will be cleaned up too.  I tend to agree with your suggestion about the rewrite rule and might even take it as far as saying that no PHP files under /mod/ can be called directly.  The biggest problem doing that is for plugins bundling 3rd party php apps.

  • I think that there should be a difference between recommended coding practices and continuing to introduce new requirements that break plugins at each Elgg release.

  • I think it is a bad idea to prevent people from calling things directly. I agree with Kevin here - keep it a recommended practice.

  • @Kevin - The changes introduced fix bugs and enhance security; they break plugins that are not written correctly or that are insecure.  There is a now applicable procedure established in CODING.txt for deprecating functions and subsystems that you might want to review if you're worried about future incompatibilities.

    @Cash - Disabling calls to any PHP file might be too much, but I'm not convinced allowing direct calls to action files is desirable or secure.  Do you have a use case where a direct call to an action file is required?

  • ajax - especially when you don't want to load the entire Elgg engine