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've one of those rare projects that combine Boost and Varnish. I noticed that, if I had the Expire module configured so it would work with Varnish, the Boost clearing functionality wouldn't work. So I've tweaked the Boost module a bit to fix that and created a patch with the change.
Comment | File | Size | Author |
---|---|---|---|
#11 | boost-allow_expiration_of_alternative_domains-2277703-11.patch | 3.12 KB | azinck |
#6 | boost-fix-expire-integration-20140531-6.patch | 2.56 KB | drclaw |
#4 | boost-fix-expire-integration-20140531.patch | 1.36 KB | SpaceGoat1701 |
Comments
Comment #1
SpaceGoat1701 CreditAttribution: SpaceGoat1701 commentedComment #2
SpaceGoat1701 CreditAttribution: SpaceGoat1701 commentedI realized the slight possibility existed of the $base_root not being in the URL because another domain might be in the URL instead. So I've created another patch to account for that. This should be used instead.
Comment #3
SpaceGoat1701 CreditAttribution: SpaceGoat1701 commentedHiding first patch.
Comment #4
SpaceGoat1701 CreditAttribution: SpaceGoat1701 commentedI reorganized the tweak again. This time, I check to see if the URL has a host name; if not, I convert the URL into an absolute one with the url function. And then I leave the rest of the code alone.
Comment #5
SpaceGoat1701 CreditAttribution: SpaceGoat1701 commentedComment #6
drclaw CreditAttribution: drclaw commentedJust to piggy back on to this Issue, I wonder if checking the
$base_root
is even a good idea at all? The logic of whether or not to expire a path shouldn't be up to boost, it's for the Expire module to determine. In my particular case, I'm working on a domain access site. I have one node published to multiple domains. When it's saved, I want to expire the page on all domains it's published to. The expire module figures this out for me, but because boost only expires pages on the$base_root
so it doesn't work.Attached patch removes the base_root check entirely. I think this might fix what the original patch was attempting to fix too so I left that bit out. If I am wrong @ SpaceGoat1701, feel free to put it back in.
Thanks!
drclaw
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedThat's an interesting comment that would probably break boost for the majority or users unless expire was merged into boost. The original issue should have probably been posted to the expire project rather than boost.
Comment #8
drclaw CreditAttribution: drclaw commentedMy comment may have been a bit presumptuous... Perhaps I can elaborate. I'm specifically referring to boost's implementation of hook_expire_cache which is an expire module hook. From my experience so far with expire, on your average non-domain_access non-multisite site urls should all be from the base root anyway (provided you enable the "Include base URL in expires" option - which, if you don't I don't believe boost will even expire anything). So, if there are urls in there with a different $base_root, I imagine it would be because someone specifically wants to clear that page from the cache. Like in my case, on a domain access site, a node that is published on multiple domains needs to be flushed from it's respective caches.
There might be other reasons for the check that I don't know so I just thought it would be worth exploring.
Comment #9
azinck CreditAttribution: azinck commentedI 100% agree with drclaw here. I see no reason for the $base_root check. I need the flexibility to clear the cache for other domains and I don't see a downside to removing this check. #6 works for me.
Comment #10
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedThis no longer applies to the latest dev version of boost :(
Comment #11
azinck CreditAttribution: azinck at Forum One commentedRe-rolled for the latest dev version. I did simplify it slightly compared to #6. #6 had added a file_exists() check before the call to unlink the file which resulted in arguably better logging but (probably) in worse performance (I confess I didn't benchmark it). Since it had nothing to do with this issue I decided to remove that change to avoid this patch getting hung up on that.
Comment #12
jollysolutionsComment #14
ram4nd CreditAttribution: ram4nd as a volunteer commented