Fork me on GitHub

Custom pager  Bottom

Go to page 1 - 2 [+1]:

  • Hi all,

    I've a question about using a custom pager, things seem to have changed slightly since RC3?

    I was using a custom pager by naming it /themes/MyTheme/templates/modules/pnRender/pagerimage.html to override the default pager. Now, my custom pager requires processDetailLinks = true. However for the pagerimage template that value defaults to false. So how do I override the default template and get processDetailLinks set to true?

    Thanks
  • Hi,

    you can either give your template another name (and use template="mytemplate.html" in your plugin call) or overwrite the pager plugin in config/plugins/ in order to reallow the processing of detail links.
    This new setting is simply a performance improvement, because the default usage, which is pagerimage.html, does not need the detailed links which makes calling pnModURL() a few dozen times worthless.

    --
    Guite | ModuleStudio
  • Hello,

    I realise why it's coded like that.

    Your first solution, unless I misunderstand, would involve adding that parameter to all pager calls in all templates to make my site consistent. The second solution is fine, but I was trying to avoid it since it's a bit of a hack, which I thought all this templating was meant to avoid?

    I take it that there is no other method?

    Thanks for your help
  • Overriding the plugin if you want different default behaviour isn't a hack - it's intended. The plugin/template system is built so that overriding is possible and encouraged - the main thing is that you don't have to edit core files to achieve anything but the most complicated changes.

    --
    itbegins.co.uk - Zikula Consulting

    birtwistle.me.uk - Personal Blog


    Please read the Support Guide
  • My mistake. I forgot that you could override the plugin, I had mistakenly interpreted that as altering the core plugin. Oops. Thanks.

    Edit: Actually, can you point me in the right direction, in which folder should I put my plugin to override the system one?



    edited by: ntward, May 23, 2008 - 05:49 PM
  • ntward

    can you point me in the right direction, in which folder should I put my plugin to override the system one?

    I would try config/plugins/function.pager.php and config/plugins/pnRender/function.pager.php - I guess the first one should work icon_wink

    --
    Guite | ModuleStudio
  • I'll give it a go. Since this customisation is to blend in with my theme, can it not be overridden in the theme/MyTheme directory somehow?

    Thanks
  • You can also use themes/{yourTheme}/plugins/function.pager.php as well as themes/{yourTheme}/templates/modules/pnRender/plugins/function.pager.php

    Lovely, isn't it icon_lol

    --
    Guite | ModuleStudio
  • Hello again,

    I've tried all three of those locations, and none of them work. The only way is to replace the system copy of the plugin. I assume that there has been performance change somewhere, since most of the time the plugins won't be overridden, so it's wasteful to check all the other directories...? Is this a bug? Or is overriding things no longer a feature?

    I'm just using RC4, not the most recent SVN.

    Thanks
  • I've never seen it documented anywhere that you can override plugins in this manner, though it would make sense to be able to do so. But I have to agree. It doesn't work. So, if it's supposed to, then this should become a bug report. Otherwise, it should become a feature request.

    After a quick 5-minute glance at Smarty, here are a couple possible reasons you're experiencing this.

    1. Plugin filepaths are cached, so if you've previously loaded a page with that plugin, then the plugin filepath would be cached and therefore the original plugin would load. Does clearing the pnRender cache clear the plugin path? I haven't figured that out yet.

    2. It looks as if the system searches for plugins first in the Smarty plugin directory, then in the pnRender plugin folder, and then everywhere else. Unless I'm reading it wrong, the first time it finds an appropriately named plugin with an appropriately named function inside, it returns that file's path to the compiler. So, as long as the plugin remains in the main pnRender plugin directory, your plugin will never be found. Again, I'm not sure that this is how it works, but at first glance, that's how it looks.

    Anyway, I guess try clearing the cache. Beyond that, let someone who actually knows how the system is supposed to work tell us whether this should be a bug report or feature request.
    Someone who knows the system will be able to answer this better. But, if you're really curious, try clearing the pnRender cache and see if it helps.

    --
    Help Now! Fast and affordable help for do-it-yourself webmasters from Wicked Viral :: Chicago's Only Web Development Firm Specializing in Social Networking Integration
  • Maybe you should read this post.
    I don't think you can override the pager plugin.

    Giacomo.



    edited by: Arthens, May 27, 2008 - 10:53 PM

    --
    Zikula Italia
    SimpleGallery
  • Thanks Arthens, I had completely forgotten about that...

    --
    itbegins.co.uk - Zikula Consulting

    birtwistle.me.uk - Personal Blog


    Please read the Support Guide
  • I understand the performance issue discussed in the cited post, but there has to be a solution to this. The problem is that a plugin like pager is used frequently by module developers. If you wanted to change its behavior, you're left with two choices:

    1. Modify the existing plugin directly - Bad because you'll lose your modifications with each subsequent upgrade.

    2. Create a new plugin with a different name providing the desired behavior - Bad because you have to go through and find all calls to the default plugin within the modules you use on your site and replace them. I suppose this isn't terribly difficult because the templates themselves can be overridden by placing them in your theme directory. But it's not really ideal.

    My proposal:

    Create a feature in the pnRender module that lists all default plugins and gives you the opportunity to check off the ones you want to override. Then add a condition to the function that builds the array containing the plugin directories that if the plugin is to be overridden, the array should be reversed before it's passed back to Smarty. That way the default locations are the last searched, meaning that the replacement would be found first instead of the default. It does add an SQL query to the process, but that's probably far more efficient than just reversing the order in which the filesystem is searched.

    This is certainly not the only solution and probably not the best one, but I've always believed that it is best to let the end user find the right balance between performance and usability.


    --
    Help Now! Fast and affordable help for do-it-yourself webmasters from Wicked Viral :: Chicago's Only Web Development Firm Specializing in Social Networking Integration
  • An afterthought (and please note that since I ran out of vanilla creamer for my coffee tonight, I've been flavoring it with Bailey's)...

    Here's a far more robust solution, but it would require re-working the way plugins are implemented. On the bright side, it would only require re-working of some portions of Smarty. It wouldn't have any effect on the way plugins are implemented within templates, so it would be a completely transparent change from a developer's standpoint. Anyway, here it is...

    What if we created a plugin registry that's handled by the pnRender module? It could search all valid plugin locations (Smarty, pnRender, all modules & themes), compiling a list of all installed plugins system-wide. The user could then view the registry, specifically a list of "conflicts" (multiple instances of a plugin name). The user could then select which of the multiple instances to use (see final paragraph if a very obvious problem just popped into your head). If the user doesn't select one, then the lowest-level (presumably default) plugin is used.

    Then, instead of searching the filesystem from bottom to top every time a plugin is called, the registry would be queried. If no match exists in the registry, the standard filesystem search would be triggered. If the plugin is found, its location(s) would be recorded in the registry and the first instance located would be executed.

    In this manner, the registry would be self-maintaining and would allow for a plugin to be overridden easily. It also has the added benefit of eliminating the filesystem search altogether in nearly all cases. One simple SQL query would determine the proper path to the plugin and it could be executed immediately.

    As a side note, if I were implementing this, I would execute a full filesystem search on the following events:

    1. Initial system install (obviously to get all default modules registered).
    2. Module init
    3. Theme list regeneration

    Some consideration would have to go into how to handle multiple instances of the same name among plugins in different modules. I might have a plugin file called function.dothis.php in my module and Joe might have the same plugin in his module. They could be totally different in nature. So, a GLOBAL/LOCAL flag should probably be part of the registry (defaulting to LOCAL for any plugins contained within a module other than pnRender or Themes), telling the system whether a plugin that exists within a module can be executed only within that module or whether it can be shared throughout the system. This would give someone the opportunity to put together a plugin toolkit as a module.

    A huge can of worms? Probably.

    --
    Help Now! Fast and affordable help for do-it-yourself webmasters from Wicked Viral :: Chicago's Only Web Development Firm Specializing in Social Networking Integration
  • How about simply adding a new setting to the pnRender module, allowing to choose the "default pager template" for the whole site?

    --
    Guite | ModuleStudio

Go to page 1 - 2 [+1]:

  • 0 users

This list is based on users active over the last 60 minutes.