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.
Hi. I'm using Boost on a high-traffic site and it's fantastic. I've been reading the documentation and there's something important I don't understand: When you update a page, does boost clear that page from the html page cache? One poster claimed that boost_nodeapi does that, but it doesn't on my server. Is there some way I'm supposed to hook it up?
If there isn't and I have to run cron, will cron clear out all my pages or just "stale" ones (one of the posts I've read implies that cron just cleans up stale pages). Any help would be most appreciated!
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#25 | boost-459530.patch | 1.02 KB | mikeytown2 |
#14 | boost-459530.patch | 526 bytes | mikeytown2 |
Comments
Comment #1
Dracolyte CreditAttribution: Dracolyte commentedHah! just figured it out. In the boost_nodeapi function, the call to expire the cache only works with pages called "node/NN". Like so:
boost_cache_expire('node/' . $node->nid, TRUE);
However, my page is called "about_us/our_mission" and so the cache_expire code doesn't delete the html. So it would seem to me that all that is needed is a more flexible param with the actual [nodename].html passed to it.Comment #2
geerlingguy CreditAttribution: geerlingguy commentedRetagging so it's in the proper queue.
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedI'm having the same kind of problem - I have boost enabled on www.lifeisaprayer.com, and I've entered the site URL into the settings.php file, and set cron to run every 25 minutes (it's verified working), yet boost won't ever clear its cache unless I go to the boost configuration page...
Comment #4
Kars-T CreditAttribution: Kars-T commentedSame problem here.
I did some debugging on this.
Only if both BOOST_OVERWRITE_FILE && BOOST_CRAWL_ON_CRON are TRUE the variable gets evaluated. And only if its FALSE the cron will do anything.
In my setup the "boost_overwrite_file" was FALSE so this gets evaluated to TRUE and the cron does not expire anything.
I am not deep into this module and hope I don't mix up any variable names but there seems to be some sort of logical problem here.
Comment #5
Cynthia Ewer CreditAttribution: Cynthia Ewer commentedSubscribing. Same problem at multisite installs http://organizedchristmas.com and http://organizedhome.com
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedSounds like we might have 3 different issues here; but who knows, maybe its all the same issue.
Going off of what Kars-T mentioned, I should put the
Expire content in DB, do not flush file. (BOOST_EXPIRE_NO_FLUSH)
setting inside the crawler block, so it is disabled unless you turn on the crawler. There are too many options, one can easily shoot them selfs in the foot right now. I need to make the configuration simpler.@organizedhome
Depending on how your server is setup, you might have to have 2 separate cron runs, one for each site, so organizedchristmas.com/cron.php & organizedhome.com/cron.php. If your running off of one database turn on this setting "Flush all sites caches in this database (singe db, multisite)."
@geerlingguy
Original poster is from May, boost is way different... anyway your issue probably got fixed in this issue #617826: Assignment instead of comparison in boost_cache_expire_derivative(). Try the dev version and let me know if it works.
Comment #7
Cynthia Ewer CreditAttribution: Cynthia Ewer commentedMikeytown, thanks.
I know this is complex. I have multi-sites running off of one code base, and one of them is running the Domain Access module. All have separate databases.
Will try any solution you suggest OR do it manually, because you're saving my Housewife Webmaster bacon right now with this module. 3 days ago, we were drowning.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commented@organizedhome
If you have separate databases for each site then you need to call cron for each site.
organizedchristmas.com/cron.php
organizedhome.com/cron.php
If you have the crawler turned on you might want to run cron at alternating times on your server, or turn the threads down, or set the crawler throttle.
Glad to hear that Boost is working for you guys :)
Comment #9
geerlingguy CreditAttribution: geerlingguy commentedI will try dev on lifeisaprayer.com as soon as I get back to the states and can upload it. Even without flushing the cache, it's helping the server run a lot better. It helped the St. Louis Review immensely as well, and I'm going to be deploying it on a much larger website sooner or later...
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commented@geerlingguy
The rate of change for boost has increased this last month, with the new cache expiration for views in place, a lot of code refactoring has taken place to take full advantage of the new functionality. As such some things have been broken, but the changes coming out the other end is pretty awesome. Here's all the patches that went in (Green), in the last 10 days
http://drupal.org/node/575840#comment-2174220. I hope to get 1.14 out the door next week.
Comment #11
W.M. CreditAttribution: W.M. commentedSame here: Boost doesn't flush expired cached files... Visitors get served the old expired pages (that's unless I clear them from Boost settings page).
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commented@Geir19
Try the latest dev, let me know if that fixes the issue for you
Comment #13
Kars-T CreditAttribution: Kars-T commentedJust to mention: I waited to see if the watchdog notice "Expired stale files from static page cache." was set. But boost_cache_expire_all() will always return false so we never get this message for log level 5.
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedthanks Kars-T for pointing that out!
Comment #15
W.M. CreditAttribution: W.M. commentedSo mikeytown2 what should I do?! The patch or the dev version?!
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commented@Geir19
Patch fixes the watchdog error, dev might fix your problem. Use the latest dev.
Comment #17
Cynthia Ewer CreditAttribution: Cynthia Ewer commentedTo clarify, the sites have shared code as multisites, separate databases, separate cache directories, and separate cron runs. One site has subdomains enabled via the Domain Access module, so each such subdomain has a cache directory, as well, but they do share a database. I have not yet enabled the crawler.
All sites are perfect candidates for Boost: 99.99% of traffic is anonymous.
Problem is that none of the site or subdomain caches are being flushed on their respective cron runs. Works beautifully if I do it manually, but we run a lot of scheduled content, so that can be tricky.
I will try the dev version to see if this fixes the problem--but again, thank you! Server load earlier in the week was exceeding capacity and crashing databases; with Boost onboard, load levels dropped by 90% and the sites are flying. Where's your donate button?
Cynthia
Comment #18
mikeytown2 CreditAttribution: mikeytown2 commented@organizedhome
Donate link is at the bottom of the release: http://drupal.org/node/610194
Go ahead and give the latests dev a shot. Let me know if it does or doesn't work.
Comment #19
W.M. CreditAttribution: W.M. commentedI will be back here and update as time passes by and pages expire!
Comment #20
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted #14. Will not fix the issues in the thread.
Comment #21
geerlingguy CreditAttribution: geerlingguy commentedI just installed the latest 6.x-1.x-dev release of Boost, ran cron a few times (after running update.php), and still didn't have any less expired pages flushed. I will let it run for a couple days and see if Boost starts flushing the pages, but I have a feeling that won't happen :-(
We shall see...
Comment #22
mikeytown2 CreditAttribution: mikeytown2 commented@geerlingguy
Can I get a screenshot of your configuration page? Use something like this to take the screenshot: https://addons.mozilla.org/en-US/firefox/addon/3408
Comment #23
jbrauer CreditAttribution: jbrauer commentedHaven't tested this yet but it looks like this is the case... If the crawler is off BOOST_LOOPBACK_BYPASS is forced to TRUE. This in turn causes boost_cron to stop at the beginning of this line
Comment #24
jbrauer CreditAttribution: jbrauer commentedTested this with the crude workaround of just removing that part of the test from line 374 of boost.module and it works. It now reads:
It seems like a little more elegant fix would be to make BOOST_LOOPBACK_BYPASS default to FALSE if BOOST_OVERWRITE_FILE and BOOST_CRAWL_ON_CRON aren't both set. So instead line 85 would become:
I'm not sure, however, what other ramifications that might have elsewhere...
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commented@jbrauer
I think thats it, It should have always been FALSE; Also thanks to Kars-T for pointing it out at the beginning of this thread.
Comment #26
mikeytown2 CreditAttribution: mikeytown2 commentedComment #27
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted
Comment #28
geerlingguy CreditAttribution: geerlingguy commentedAwesome! Are you still planning on pushing 6.x-1.14 in the next week or so? If that's the case, I'll just hold off until then. Thanks again (like others have said) for one of the most awesome Drupal modules in existence (in my opinion!).
Comment #29
mikeytown2 CreditAttribution: mikeytown2 commented1.14 will be pushed out once I hear back on the status of this patch, if it fixes a long standing bug or not. I expect it to be out early November.
#305071: user logout, Header unset ETag & browser caching front page
For an overview of where this is headed and what will be in 1.14 (what you already have with the latest dev) this is the thread for you
http://drupal.org/node/575840#comment-2174220
Comment #30
W.M. CreditAttribution: W.M. commentedmikeytown2: Thanks for great work.. I realized how much code goes into this as I applied the patch.. I applied the recent patch on the latest dev version and problem solved! I can confirm that.
I have one question regarding the settings under /admin/settings/performance (that come with Drupal), should caching be set to off there?! I think this needs better documentation in Boost..
I have also discovered that running cron using "domainhere.com/cron.php" results in cron running fine but results also in a "page not found" error/page (instead of a blank white page - as it did before). I am not sure if this is related to Boost ?!
Comment #31
mikeytown2 CreditAttribution: mikeytown2 commented@Geir19
That could be related to this recently fixed bug if your running the latest dev.
#619934: CRON generates a "Page not Found" error...
You can set the cache to whatever you like... if boost will not cache it, then core might be able to. so enabling both is perfectly fine, they will not conflict. It all depends on what you want the cache to do... lots of options. I personally don't run with the core cache on.
Comment #32
Cynthia Ewer CreditAttribution: Cynthia Ewer commentedWhoo-HOO!
The latest fix did the job. All caches duly cleared on cron run after installing the Nov. 1 .dev version.
Thank you SO much, Mikeytown. This is a fantastic module. Off to show some gratitude.
Cynthia
Comment #33
mikeytown2 CreditAttribution: mikeytown2 commented@organizedhome
Thanks for your support!
Comment #34
tntclaus CreditAttribution: tntclaus commentedIt seems I have the same issue. Installing 1.14 didn't help. I've set html cache 15 min. Cron runs every 20 minutes, but expired cache doesn' flush :( The cached pages stay at their folder (cache/normal/sitename/), the number of expired cache pages at admin/settings/perfomance/boost doesn't reduce etc.
Comment #35
tntclaus CreditAttribution: tntclaus commentedI dunno what I did, but now it works.