Not Purging since 3.7.2

The only reason I can think of that it’s not happening is that the php shutdown isn’t actually being called.

I am on this version of PHP: PHP Version 5.4.41-0+deb7u1

That’s not quite what I meant ?? If you have something (say a plugin) that prevents PHP from recognizing that it’s done with everything, that could prevent this from running properly.

hehe OK. I wish you luck diagnosing, if there is anything else I can provide let me know.

Do you have plans to implement per page purging instead of emptying the whole cache only?

Well … per page is what it actually does when it works.

You add or edit a page, it flushes that page, the first page for your ‘show blog posts’ page, the home page, the first page for cats and tags, and the rss feeds.

The purge all button is just for people who do things like edit CSS direct on the server.

Oh ok, I guess I never noticed since it didn’t work for me. I assumed purge just purged everything. Cool to know it purges intelligently.

I’m having issues as well. Just gave this plugin a try running varnish3 + nginx and I’m on cloudflare as well. I edited a js file in my theme dir and the tried the purge button but same js file.

Varnish configured like blindpet listening on 127.0.0.1 and I tried:

curl -X PURGE “https://127.0.0.1/.*” -H “host:https://www.myrealdomain.com”

which results in a 200 as well. But original js file still loads even if I delete it. I’m thinking cloudflare changed something we need to know about.

EDIT: Tried using W3 total cache and checking the ban.list and it is the same regex I was seeing with this plugin. Something strange with cloudflare.

varnish> ban.list
200
0x7f7298803700 1438059969.321511 1 req.http.host == https://www.myrealdomain.com && req.url ~ /.*

Something strange with cloudflare.

Well there’s your problem.

The way I’ve suggested people use the curl with cloudflare is that https://127.0.0.1/ is the public IP for apache (or nginx, though I’ve not testing with that). 127 is like saying localhost. What’s the /etc/hosts/ file got for the internal IP?

Yes that’s exactly what it is, localhost. My hosts file only has entries for:

127.0.0.1 localhost
127.0.1.1 ubuntu

The big clue is when I clear varnish for edits to any php file it works every time but not for css and js files so my temporary workaround is to add my minor script/style edits inline after wp_footer in my footer.php until I can get this figured out. Would a gist of my default.vcl help?

My host has given me the url direct.myrealdomain.com as a way that is supposed to bypass cloudflare and the issue persists there as well.

And it’s only css and js? Then… My guess is you’ll do this:

1) Flush Varnish
2) Flush CSS/JS on cloudflare

See if that order works?

My problem is my client’s host is a marketing company and they hold the keys to the castle as far as cloudflare. I’m looking into if the clouflare API allows me to perform the flush or not via API and if so maybe they will release the key to me. *fingers crossed*

However, one big clue is that the css and js files are minified and I don’t see any plugins or functions doing that from within the wp installation and my understanding is that varnish does not provide minification directly. I know it’s server side because when I bypass clouflare the files are still minified but yet still the previous versions. I’m using https://www.isvarnishworking.com to verify my “direct” url is bypassing cloudflare and it is so I’m still left with the strong feeling that my issue is server side.

Thanks for your continued input btw as it seems pretty clear this is not a fault of your plugin.

That is very weird, you’re right. Nothing in WP does compression, and I THOUGHT Varnish wouldn’t actually cache the compressed files since those never touch it (they’re on CloudFlare).

You don’t have anything daft like PageSpeed running, do you?

https://www.cloudflare.com/docs/client-api.html has some info on fpurge_ts which should flush the cache.

I confirmed its cloudflare’s cache that is the problem. I was wrong, the bypass of cloudflare was still loading the scripts/styles from the https://www.xxxxx.com versus the direct.xxxxx.com.

Looking at the direct.xxxxx.com/wp-content/…/style.css was not minified so that is definitely cloudflare performing that & their caching was the issue.

(╯°□°）╯︵ ┻━┻

CLOUDFLARRRRRE!

I have ended up doing something much better which warms up and refreshes the Varnish cache (using req.hash_always_miss) without purging so cached pages are always served. I have detailed how easy it is to set up and provided 3 scripts which should be easily adaptable for the plugin.

https://www.htpcguides.com/smart-warm-up-your-wordpress-varnish-cache-scripts/