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.

CommentFileSizeAuthor
#11 boost-allow_expiration_of_alternative_domains-2277703-11.patch3.12 KBazinck
#6 boost-fix-expire-integration-20140531-6.patch2.56 KBdrclaw
#4 boost-fix-expire-integration-20140531.patch1.36 KBspacegoat1701
#2 boost-fix-expire-integration-20140531.patch2.95 KBspacegoat1701
boost-fix-expire-integration-20140531.patch2.81 KBspacegoat1701

Comments

spacegoat1701’s picture

spacegoat1701 commented
Issue summary: View changes
spacegoat1701’s picture

spacegoat1701 commented
StatusFileSize
new boost-fix-expire-integration-20140531.patch2.95 KB

I 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.

spacegoat1701’s picture

spacegoat1701 commented

Hiding first patch.

spacegoat1701’s picture

spacegoat1701 commented
StatusFileSize
new boost-fix-expire-integration-20140531.patch1.36 KB

I 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.

spacegoat1701’s picture

spacegoat1701 commented
Status: Active » Needs review
drclaw’s picture

drclaw commented
StatusFileSize
new boost-fix-expire-integration-20140531-6.patch2.56 KB

Just 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

Anonymous’s picture

Anonymous (not verified) commented
The logic of whether or not to expire a path shouldn't be up to boost, it's for the Expire module to determine.

That'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.

drclaw’s picture

drclaw commented

My 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.

azinck’s picture

azinck commented

I 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.

socialnicheguru’s picture

socialnicheguru commented

This no longer applies to the latest dev version of boost :(

azinck’s picture

azinck commented
StatusFileSize
new boost-allow_expiration_of_alternative_domains-2277703-11.patch3.12 KB

Re-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.

jollysolutions’s picture

jollysolutions
one/the
commented
Status: Needs review » Reviewed & tested by the community

  • ram4nd committed 9109d2d on 7.x-1.x authored by azinck 
    Issue #2277703 by SpaceGoat1701, drclaw, azinck: Fix integration with...
ram4nd’s picture

ram4nd commented
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.