Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have noticed that Boost will cache pages even when there is no working connection to the database. This causes anonymous users to be served pages with error messages stating "MySQL server has gone away" even after MySQL has been restarted. The only way I know to solve this currently is to clear the entire Boost cache.
It would be great if there was a way for Boost to test for a MySQL connection before caching pages.
Comment | File | Size | Author |
---|---|---|---|
#21 | boost-385924.4.patch | 3.13 KB | mikeytown2 |
#18 | boost-385924.3.patch | 5.53 KB | mikeytown2 |
#17 | boost-385924.2.patch | 5.53 KB | mikeytown2 |
#16 | boost-385924.1.patch | 3.52 KB | mikeytown2 |
#15 | boost-385924.patch | 2.13 KB | mikeytown2 |
Comments
Comment #1
EvanDonovan CreditAttribution: EvanDonovan commentedMaybe this should actually be a feature request, but I think it would be great if Boost didn't cache pages when either the MySQL connection was down or when there were fatal PHP errors.
I know the Authcache module handles the latter case as follows (in the _authcache_shutdown_save_page() function of authcache.helpers.inc, lines 116-119):
Since I think a broken MySQL connection causes PHP errors that might actually solve both cases at once. I'm not completely sure.
Comment #2
EvanDonovan CreditAttribution: EvanDonovan commentedComment #3
mikeytown2 CreditAttribution: mikeytown2 commentedI'm currently in Los Angeles (not home) until the 20th, but this will be a top priority once I get back. Fix is easy, if the above code you gave is correct.
Before
After
While here we should also check for drupal messages; those shouldn't be cached.
http://api.drupal.org/api/function/drupal_set_message
http://api.drupal.org/api/function/page_get_cache
Comment #4
EvanDonovan CreditAttribution: EvanDonovan commentedSounds great. They check for those in Authcache as well; I can find the specific code if you need it.
Comment #5
EvanDonovan CreditAttribution: EvanDonovan commentedSomething that may be a problem, though, is error reporting level. When installing Authcache a few days ago, I found pages were not being saved to the cache due to an E_NOTICE-level error. Since those could happen quite frequently on some Drupal sites, and don't generally show to the screen, then this check would stop more pages from being cached than necessary.
Therefore, the checking code might need to be more elaborate, similar to that in comment #2 of http://php.market.in.th/manual/sl/function.set-error-handler.php.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedHere's a list of errors
http://www.php.net/errorfunc.constants
http://www.php.net/error_get_last
If you could write the logic so it only halts on critical & writing to the output, errors that would be quite helpful.
Comment #7
mikeytown2 CreditAttribution: mikeytown2 commentedI think these are the 4 errors in which boost should ignore and cache the page
So this is what the new code block would look like
Comment #8
EvanDonovan CreditAttribution: EvanDonovan commentedSounds good. But what if there were an error message that was generated on the page request and printed to the screen after the boost module had already passed the init hook?
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedGood point, I'll add the error checks into the _boost_ob_handler() function, so
count(drupal_get_messages(NULL, FALSE))
anderror_get_last()
would go in there.Comment #10
EvanDonovan CreditAttribution: EvanDonovan commentedThat's good - that's exactly how Authcache handles it.
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedDecided to clean up boost_init while we are here. This really hasn't been tested since I have to run; will test later.
Here's how it looks
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedTested above code and it works; meaning the hook_init rewrite is good. Inside the patch is the do not cache errors code as well; this is a little bit harder to test so any error testing is greatly appreciated.
Comment #13
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedAdding code to boost block so admin knows the page can not be cached due to php/drupal errors/messages. Also used hook_help as a hack to get the correct values from drupal_get_messages().
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedChanging above patch do to this issue #480266: PHP < 5.2.0 - No files created since update to 6.x-1.0-beta1 due to missing error_get_last(). Also did some code cleanup of the patch.
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedincorporating #480266: PHP < 5.2.0 - No files created since update to 6.x-1.0-beta1 due to missing error_get_last() into this patch since it's related. Formatted the block better as well.
Comment #17
mikeytown2 CreditAttribution: mikeytown2 commentedAdded a setting to control if boost will cache on errors.
Comment #18
mikeytown2 CreditAttribution: mikeytown2 commentedComment #19
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted
Comment #20
XerraX CreditAttribution: XerraX commentedif i uncheck the new checkbox and save the settings, the checkbox is checked again
Comment #21
mikeytown2 CreditAttribution: mikeytown2 commentedI can not confirm this, it works for me. Try unchecking it one more time; it makes no since. In the mean time I've done more cosmetic changes to boost's watchdog errors, and added more as well. Also changed the default to false, because php throws errors too easily.
This patch requires the one above to be applied first.
Comment #22
mikeytown2 CreditAttribution: mikeytown2 commentedComment #23
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted above changes so next dev will have the default set to false
Comment #24
XerraX CreditAttribution: XerraX commentedOk it was my fault, somehow the previous patch messed up my module file. I re applied Patch 3 and then Patch 4, now everything is working as expected.
Thanks for all your support and this great module.
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commented