In trying to troubleshoot why Boost was not caching any pages, I noticed that $_boost['cache_this'] array key is never set to TRUE in the module code. It would seem that this key should be being given a default value of TRUE once it clears the nested if condition in the boost_init() function. This doesn't necessarily seem to matter, as long as $_boost['cache_this'] is not set to FALSE, but leaving it unset seems counter-intuitive to having the key in the first place. Is there a reason for this?

Also, the originating problem came down to the drupal_page_is_cacheable() in boost_exit() being heavy-handedly and unnecessarily set to FALSE by some other module/code in the bootstrap - TBD. Though this is not a Boost issue per se, there is currently no way to intervene proximate to this conditional evaluation other than doing something really hacky, like jumping in at hook_page_alter() or another instance of hook_exit() and hoping that the reset is picked up prior to Boost's evaluation of the function.

Have you considered dropping a hook into the boost_exit() function to allow for opening up the logic, so that false negative's can be evaluated, confirmed, and bypassed/reset to TRUE without having to hack the Boost module?

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Have you considered dropping a hook into the boost_exit() function to allow for opening up the logic, so that false negative's can be evaluated, confirmed, and bypassed/reset to TRUE without having to hack the Boost module?

A hook has not been considered. Although I take on board the comments about the variable being unset, boost is foremost an anonymous caching mechanism and most of the bug reports turns out to be either incorrect configuration or a module that is setting a drupal core cookie (when it should set it's own), which then in turn sets boost's DRUPAL_UID cookie and disables it.

The problem with a hook is that it quite possibly it would be needed to change the .htaccess rules which are in place for the prevention of showing tailored content to anonymous users (like creating an if block around DRUPAL_UID of just ignoring it) and that could be bad for security or the other scenario is that everyone would see one person's tailored content as it's stored as static html.