ingraye

Correction to myself, the code should be:
$terms = array_map( ‘intval’, json_decode($entry[ $field->id ] ));

To typecast the values into int for hierarchical taxonomies.

In general, the method is you edit a page, the cache auto flushes that page (and some related pages to ensure everything matches) and off you go.

Wouldn’t that be better as a ‘paste the URL here to flush this page’ sort of thing? Forget going to a specific page, just have a box to paste in the URL?

Yes and no. For me, it would be easier to do a text dump of URLs to purge (and I can just do that via the varnishadm) but my editors found it easier when they navigated around and saw “hey, this looks like it needs to be updated” to just click the button to purge the cache for the page.

We do use the last modified value of the post for certain purposes so just updating the post isn’t ideal. I actually don’t remember right now but I believe that the version we’re using purged just that specific page. With the user-agent to purge all versions of the cache, the standard “update purge” sends about 20ish requests (4 times each page due to the user-agents). Probably more.

I was going to fork the one you have in github but I see that version is a bit ahead of what’s released.

I made a new repo, put the 3.7.3 file there. Then the changes to it that I used for the user-agent and then made a new branch of that for the purge varnish button changes I did (since that change is probably specific to me).
https://github.com/madavorMichaelMa/varnish-http-purge/commits/

Basically, my Varnish VCL uses a modified version of the devicedetect that’s out there (mostly the same but I reduced the total amount of devices identifiers that are passed) since some of the sites I manage have different versions for mobile, tablet and desktop. Purging the cache when a person made an update only purged the desktop (WordPress user-agent resolved to desktop as “other”) so I needed to be able to pass in user-agents to purge all versions of the cache. Added in the filter to allow you to pass in user-agents that it will loop through.

For the Purge Varnish button, I never found a good use for it in it’s current implementation. Wiping the entire cache is an extreme measure and rarely ever needed to be done for me. But purging a specific page URL is something my editors have requested quite often. Plus, I never liked that the button to wipe the entire cache was just a few pixels away from the “edit post” button.

So I modified the Purge Varnish button in the admin tool bar to “Purge Varnish URL” which will purge the current URL as if you made an update to the page (even allows you to purge static files by manually editing the request). Since this isn’t as extreme as purging the entire cache, I was more than happy to allow editors access to this (debatable for others I guess).

I had the same issue with a huge relatively (?) big CDN (10k+ files). You need to modify your php.ini to allow longer execution times. I’m not sure why the script needs so long to load the page. Trying to figure this out myself but not finding any answers.

Nevermind, I think it’s a plugin that’s doing it.