Not Purging since 3.7.2

I’ll have to think about that. It requires a VCL change which is a bigger drama for the intended audience than you’d think (I’m aiming this for managed WP hosted people, not users like you and me).

I hear you, I’m not suggesting it replaces existing functionality but that it is an option. To be fair the vcl change is minor but even the smallest changes can throw a wrench in the works for many users.

I always assumed managed WP host people needed to set up a vcl anyway if Varnish was in their cpanel or whatever it’s called.

The alternative for me is to get a plugin created that does this, is the current plugin on github so it can be forked and this functionality added by somebody who knows php better than me?

I plan to never purge again ??

The hosts set up the VCLs and lock them down on Managed WP hosting. Basically it’s alike a VPS for dummies. No admin access, no root access. You get treated like a Shared User (no power tools) but with VPS power. I’d have to play around with how to check if the rule was there and run it instead, without hassling the users.

Of course this is on Github ?? https://github.com/Ipstenu/varnish-http-purge

The current version there is a beta which doesn’t seem to work for everyone (per the report of one person who said it broke, I’ve been testing it quietly).

Where are the hosts getting VCLs from? If there is some place they get them I can put the info there so they can update them, it really isn’t reinventing the wheel as you can see.

I guess I was ignorant about how many people use shared hosting, that’s really sad.

If you manage to implement it that would be amazing.

I will watch the git version to see when it is stable. I will try and find time to test it should you implement this feature. Is the current version of the plugin in the WP repo the one on github – you seem to imply it is different.

The hosts make their own VCLs. You can make the code public, but getting them to use it is the problem :/

For self-hosted Varnish, that’s not a big deal. For the managed, they’re likely not to want to add in changes without a lot of testing and approvals.

The Git Version is in beta right now. I’m backing out a change but since WP 4.3 is due up this week, it may be a bit before I get to it.

OK cool, what is the best way for me to monitor for a new version that support this? Mailing list or anything?

Also where can I get the original varnish graphic you are using, I’d like the bunny with the hat centered in a cloud and my feeble attempts to manipulate the one you are using failed. Any help would be appreciated.

Also, if you are interested I can hire you to code the updated version of the plugin, are you on freelancer or anything?

No, I’m not a Freelancer ?? I work for DreamHost as a WordPress expert and developer.

3.8 on https://github.com/Ipstenu/varnish-http-purge is now working properly so it’s safe to build off of. I’m just waiting on a coworker to double check that I didn’t derp anything.

I don’t remember where I got the bunny on the cloud image… A lot of logo searching ??

Very cool, well as you can probably see I’m willing to speed this along so if we can arrange something privately let me know.

My logo searching is giving me nothing as cool as the purple hatted bunny.

I’m having a similar issue here with CloudFlare and DreamPress. I’m trying to clear one CSS file out of the varnish cache, and it refuses to show me an updated version in my browser with cloudflare on.

If I use the command:
curl -X PURGE "https://my.dreampress.ip/wp-content/path/to/my/css\.css" -H "host:https://www.mydomain.com"

it does return an Error 200 purged. But this command only successfully clears my target css file when I’m not routing my services through CloudFlare. As soon as I turn CloudFlare back on (by clicking the “arrow through the cloud” symbol on the dashboard), then this file still shows up as the wrong, cached file.

Same thing happens with your plugin. It works just fine with cloudflare off, but with cloudflare on, the files don’t actually refresh in the varnish cache.

I’ve working with Dreamhost support to update my ACL lists, but I’m not hopeful (as these examples are generally specified toward NGINX and not Apache). Would love to hear if you have anything else to try.

@websymphonies the way to work around this is to use the actual IP and not the domain name. I have a beta plugin that works around this and would love for you to help me test it. You can use my contact form on htpcguides.com to arrange testing.

@blindpet You mean use the actual IP address within the plugin?

Event when I strictly use my IP address via SSH:

curl -X PURGE "https://1.2.3.4/wp-content/my/path/css\.css"

It shows as Error 200 purged, but with cloudflare on, the file is still old in the browser.

Is that what you mean? Do you have a beta plugin that resolves this issue?

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.

I have had your issue before even when purging manually, I found it it was CloudFlare caching the css file. I am making a plugin for that too so pages/files can be selectively purged from CloudFlare too.

Well, what’s strange is that I’ve added a cloudflare exception for my CSS file. So cloudflare isn’t supposed to be caching that file at all right now. But when I try to view the file via a browser, it’s not the same file that shows up in via FTP (the real file). Obviously it’s still cached somewhere, even if the varnish cache says Error 200 (which should be successful).

Yea, this can be the issue with caching everywhere (I do it myself, max speed), that is why I’m trying to automate these things.

Development mode in a separate browser can help diagnose where the cache lies.

I would definitely purge the specific file manually in CloudFlare.

Hope you get in touch for testing

I would definitely purge the specific file manually in CloudFlare.

Unfortunately, I’ve tried manually purging the file as well via CloudFlare’s interface, and this CSS file still shows up without my modifications.

I have no other workaround other than to disable cloudflare entirely when I want to make changes to the website.