Not Purging since 3.7.2

And when you view the source of the file from your domain it is unaltered?

When my theme changes I purge css files from Varnish then purge the same ones on CloudFlare and it works.

Only other thing I can think of is browser cache and/or minification cache.

And when you view the source of the file from your domain it is unaltered?

The actual CSS file itself, on the server, has been modified via FTP. When I clear the varnish and clear cloudflare cache, the CSS file still shows up as an older version.

I’m clearing my browser cache each time and also trying incognito windows.

Where is the minification cache? How do I clear that?

Compare these three files to find the caching culprit

IP of webserver css file
domain name css file
FTP css file – can be different from the IP web server css file if Varnish still has a cached version

Minification cache is only if you use a minification plugin like BWP minify and CloudFlare is caching the combined/minified versions of files

Well, somehow it’s working now. Some combination of what I tried seems to have worked.

I added a special exception in cloudflare for a second time for that CSS file, and I had Dreamhost add my server’s IP and my website’s domain name to the etc/hosts file (though this didn’t fix the issue yesterday, so I doubt this worked).

But now when I clear the varnish cache after updating my CSS file it seems to be working. The updated CSS file is displaying.

Though when I try to do a wp cache flush command as per Dreamhost instructions, it’s now saying curl: (7) couldn’t connect to host. I’m assuming this has something to do with my etc/hosts file modifications.

But at least it’s working now.

Glad you got it fixed, I attempted to send you a message through your website to test the beta plugin (and for design work) but I only got a white page after clicking send.

@blindpet Thanks! It’s odd that the form didn’t go through. I attempted to contact you on your website as well. you can also try to email creations@websymphonies

I am not sure the plugin lets you specify the IP but I could be wrong. I moved on to other options when I couldn’t get it to work.

Totally does. Has since the day I took it over. From the FAQ:

Why aren’t my changes showing when I use CloudFlare or another proxy?

When you use CloudFlare or any other similar servive, you’ve got a proxy in front of the Varnish proxy. In general this isn’t a bad thing. The problem arises when the DNS shenanigans send the purge request to your domainname. When you’ve got an additional proxy like CloudFlare, you don’t want the request to go to the proxy, you want it to go to Varnish server.

To fix this, add the following to your wp-config.php file:

define('VHP_VARNISH_IP','123.45.67.89');

Replace “123.45.67.89” with the IP of your Varnish Server (not CloudFlare, Varnish). DO NOT put in http in this define.

You can also set the option vhp_varnish_ip in the database. This will NOT take precedence over the define, it’s just there to let hosts who are using something like wp-cli do this for you in an automated fashion:

wp option add vhp_varnish_ip 123.45.67.89

and

wp option update vhp_varnish_ip 123.45.67.890

Now that said it you’re getting “curl: (7) couldn’t connect to host. “

It’s PROBABLY because curl and Cloudflare need extra love.

curl -X PURGE "https://123.45.67.89/.*" -H "host:https://www.example.com"

Hi Mika,

Thanks for your reply. It looks like that DEFINE variable in my wp-config was already there, though I don’t remember putting it there.

If I tell cloudflare to ignore my CSS file, then the varnish purge feature of your plugin seems to do the trick now. But when I have cloudflare enabled for my CSS file, and try to purge both cloudflare and varnish, it still shows the old file. Very puzzling.

That “curl(7) couldn’t connect to host” message started showing up after Dreamhost Techs inserted my IP/websitename into my etc/hosts file. I asked them to do this, as someone had recommended it, and I was hoping it would cause my server to cut Cloudflare out of the equation. Not sure if I should have them remove it or not now that at the very least I can get the file to purge when CF isn’t caching it.

Thank you Mika, serves me right for not RTFM ?? I was looking for a settings page or something. I do need more control of my cache so a custom plugin was the way forward anyway.

I did not know about the -H so thank you for that. Is that something that concerns multisite? If you are curling the web server directly why would you need to add some extra love for CloudFlare if it is already being bypassed?

If I tell cloudflare to ignore my CSS file, then the varnish purge feature of your plugin seems to do the trick now. But when I have cloudflare enabled for my CSS file, and try to purge both cloudflare and varnish, it still shows the old file. Very puzzling.

Huh. I wonder if a race condition. Like are you flushing Varnish and THEN Cloudflare? That should work, logically…

CSS is really messy, though.

But wait, you’re on DreamPress right? So once you change the CSS can you see the change on https://www.domain.com:80/wp-content/my/path/css.css ?

Check that before you tell Varnish to flush and then before Cloudflare.

Also if you’ve ONLY redirected https://www.domain.com to cloudflare (and not non-www) then you SHOULD be able to check on domain.com/wp-content/my/path/css.css for the changes.

Of course you’ll have to do this:

curl -X PURGE "https://123.45.67.89/.*" -H "host:https://example.com/

(notice the lack of www in the https://example.com). varnish is s simple creature.

That “curl(7) couldn’t connect to host” message started showing up after Dreamhost Techs inserted my IP/websitename into my etc/hosts file. I asked them to do this, as someone had recommended it, and I was hoping it would cause my server to cut Cloudflare out of the equation. Not sure if I should have them remove it or not now that at the very least I can get the file to purge when CF isn’t caching it.

I would ask them to remove it. if it’s blocking curl, then a mess of other things won’t work quite right.

I did not know about the -H so thank you for that. Is that something that concerns multisite? If you are curling the web server directly why would you need to add some extra love for CloudFlare if it is already being bypassed?

Because Curl’s silly and because domain.com resolves in DNS to the cloudflare proxy and not your server.

CURL has to be set to the server, and the only way to specify that is by the IP. When you say curl -X PURGE https://domain.com then you’re literally asking your server to hit domain.com

That’s why websymphonies’s ‘fix’ to edit /etc/hosts actually kinda works. Sometimes. Instead of using proper DNS resolution, when you ping domain.com from his server, it doesn’t resolve to CloudFlare but itself.

That said, it can have other implications, since you are actually using Cloudflare there :/ Which in turn is why the plugin passes the IP through things when provided, to say “Don’t listen to DNS or use the proxy, use my IP, and flush for this domain host please.”