Fork me on GitHub

Pages module and cache control  Bottom

  • I've a particular block which need a lot of time to be computed (finding new files on the hard drive) and I want to compute it as little as possible. So I put it in cache but when I access to a page of the Pages module, the block is systematically computed once (even if the block is already cached). After somes investigations, I've found my problem, we have in the pnuserapi.php of the Pages module these lines :

    Code

    if ($args['parse']) {
            $pnRender = pnRender::getInstance('Pages');
            $pnRender->force_compile = true;


    Why force the compilation in this case ? I dont' understand. Someone has an idea ?

    --
    "Power corrupts. PowerPoint corrupts absolutely."
    My personnal (french) Websites: http://www.xbee.net (PN .8)
    and http://fczone.xbee.net (PN 0.764)
  • May'Bee' pages could be updated on a daily/hourly basis.... icon_smile

    Anyway, good point...

    - Igor
  • While they could be, the point of Pages in my opinion was for 'static' content.

    --
    David Pahl
    Zikula Support Team
  • So, it is an unwanted feature or a bug ? :) For my case, the Pages module works without force_compile set to true.

    --
    "Power corrupts. PowerPoint corrupts absolutely."
    My personnal (french) Websites: http://www.xbee.net (PN .8)
    and http://fczone.xbee.net (PN 0.764)
  • The Pages module probably haven't been written with caching in mind. Even if it's "static" then the output depends on users permissions (if you change your permissions then you will only see the same old pages as you did before). It also shows author name (I guess) - that won't change if the author changes it's display name (this could be solved with a few nocache tags).

    Anyway - the problem here is more likely that we use a static instance of pnRender, so you block will use the cache settings left by the Page module. Your block should set $pnRender->force_compile = false; itself. You can also just create your own pnRender instance.

    The static pnRender is used for performance reasons - it turned out that creating a pnRender instance took quite some time, so we save one static version for everybody to use.
  • Ok, I understand that it is a problem of restoring global context but I don't understand why the Pages module must set the force_compile flag in this part of the code. The Pages module uses standard caching features so the first time, these lines are executed but after that, the static page is in cache and they are no more used. Why don't use the global force_compile flag as others modules ?

    --
    "Power corrupts. PowerPoint corrupts absolutely."
    My personnal (french) Websites: http://www.xbee.net (PN .8)
    and http://fczone.xbee.net (PN 0.764)
  • xbee

    Why don't use the global force_compile flag as others modules ?


    Don't now.
  • Ok, I submit a bug report ...

    --
    "Power corrupts. PowerPoint corrupts absolutely."
    My personnal (french) Websites: http://www.xbee.net (PN .8)
    and http://fczone.xbee.net (PN 0.764)
  • The purpose of the force compile here is purely for the internal (in memory) compilation of the page content. What we do is treat the data entered by the user as a 'template'. This allows for users to put pnRender/smarty tags into pages.

    Without the force compile one page content would overwrite the other as Smarty is using the variable name as the compile id. However this has some impact on the pnRender singleton. The same code is used currently in the htmlpages module - but this doesn't utilise the singleton.

    -Mark

    --
    Visit My homepage and Zikula themes.

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