nachtigall

I’ll push to GitHub as a beta later today (this is one of my many things to mess with today).

Thanks!

It’s because we’re detecting pages before we run the purge actually. We have to verify how far back to go and I cannot assume regex for all things (which is spendy on the cache end).

Please reconsider. In this case it is just 2 Purge requests (/blog/page/2/ and /blog/page/3/). In case of “/blog/page/[0-9]*” (better “/blog/page/[0-9]+”) it is an extremely easy to evaluate regex, this is definitely less than 1ms of CPU time on any hardware build after 2000. Also, this is only occurs whenever you really edit a page, that is very rarely.

Also I’m sure that nobody has ever complained about w3tc doing it this way.

Also keep in mind, this plugin is trying NOT to flush everything that might possibly be touched.

I am not talking about what be might possible be touched but what has definitely been touched. If you add a new post, you definitely have to purge “/blog/page/[0-9]+”

A cache page expires after a while anyway, if you configured Varnish right they should expire regularly. I think we set up the servers here to assume a page is stale after 5 minutes. Static files are much longer, but given the dynamism of sidebars and footers with feeds etc, we felt it a better balance.

I’d like to set it to 2 hours or more using Cache-Control headers. The only reason I cannot is that this plugin purges only 10 URLs (see above) when I should be actually 13 URLs (the 10 + “shop” + “/blog/page/2/” + “/blog/page/3/”).

In my case sidebars and footers are very static and only change every few months.

So it’s a real PAGE though and not something dynamically generated by Woo? Like you can edit the page in the page editor and everything?

Yes, I can edit it. It is just an empty page, see this screenshot from my local dev machine for illustration: https://storage4.static.itmages.com/i/15/0305/h_1425597044_5629649_2752f6e27b.png

If I write something in the text field this simply shows up above the Woo generated shop stuff.

Solved the /blog/ part.

Cool ?? Can you commit this on https://github.com/Ipstenu/varnish-http-purge, so I can test it?

The sub-pages, I see what they’re doing. Not sure I want to have this plugin get that heavy.

I do not understand what should be heavy about this? Is it because, it is a few purge requests more? (In its easiest form just do a "/blog/page/[0-9]*" request regex).

If pages get stale, then these must be purged immediately, otherwise users will see incorrect pages and that’s really a heavy error. Regarding caching there is nothing worse than delivering a stale page. I’d rather do a Purge too often, than having stale pages in the cache ?? (and these are not even unnecessary, “too often” Purges, they are correct and needed)

Regarding the shop URL, is that a specific page that has a short code on it, or is it something auto-generated by Woo?

This page (the one for /shop/) is just empty (it exists as page though), no shortcode in it. Here are the available shortcodes for woocommerce. There is no shortcode for a shop in it, so I think that it is auto-generated somehow.

…. just quickly testing with w3tc ….

When I edit /shop/filter-stellers-jay/, then w3tc purges these pages:

"PURGE / HTTP/1.1"
"PURGE /blog/ HTTP/1.1"
"PURGE /blog/page/2/ HTTP/1.1"
"PURGE /blog/page/3/ HTTP/1.1"
"PURGE /feed/ HTTP/1.1"
"PURGE /shop/filter-stellers-jay/ HTTP/1.1"
"PURGE /([a-z0-9_\\-]*?)sitemap([a-z0-9_\\-]*)?\\.xml HTTP/1.1" 501 497 "-" "W3 Total Cache/0.9.4.1"

As you’ll notice /shop/ is not among it (which is an error). (BTW, the 2nd, 3rd and 4th would not really be necessary, but as said above, rather ones too often then ones too less ??

Hint: According to API you could do:
$shop_page_url = get_permalink( wc_get_page_id( 'shop' ) );

Last not least I want to say: Thanks for getting this far already, really great support!

It works with w3tc

When editing /blog/roasters-united-treffen-auf-mallorca/ then your plugin purges the following:

"PURGE /category/roasters-united/ HTTP/1.0"
"PURGE /blog/roasters-united-treffen-auf-mallorca/ HTTP/1.0"
"PURGE /feed/rdf/ HTTP/1.0"
"PURGE /feed/rss/ HTTP/1.0"
"PURGE /feed/ HTTP/1.0"
"PURGE /feed/atom/ HTTP/1.0"
"PURGE /comments/feed/atom/ HTTP/1.0"
"PURGE /comments/feed/ HTTP/1.0"
"PURGE /blog/roasters-united-treffen-auf-mallorca/feed/ HTTP/1.0"
"PURGE / HTTP/1.0"

whereas w3tc purges these:

"PURGE / HTTP/1.1"
"PURGE /blog/ HTTP/1.1"
"PURGE /blog/page/2/ HTTP/1.1"
"PURGE /blog/page/3/ HTTP/1.1"
"PURGE /feed/ HTTP/1.1"
"PURGE /blog/roasters-united-treffen-auf-mallorca/ HTTP/1.1"
"PURGE /([a-z0-9_\\-]*?)sitemap([a-z0-9_\\-]*)?\\.xml HTTP/1.1"

So /blog/ is in here (even /blog/page/2/ and /blog/page/3/ are in, which is nice and correct actually).

(but I really do not want to use w3tc as it goes very deep into the whole system, I used it for some time but deinstalled it later. I’d really rather like to use your plugin ??

Yes, I will test with w3tc but why not just adding these filter hooks anyway?

PPS vhp_purge_paths (just an array of absolute paths not urls like [/, /blog-post-path, /cat-path] would be better then vhp_purge_urls.

Purging of https://www.fiveroasters.de/feed/ works (just tested by editing a blog post: the feed was correctly purged).

Used plugins are:

Akismet
Easy FAQ with Expanding Text
Google XML Sitemaps
Groups
MailChimp for WordPress Lite
Paymill
Page Builder by SiteOrigin
Varnish HTTP Purge
WooCommerce Germanized
WooCommerce Google Analytics Integration
WooCommerce PDF Invoices & Packing Slips
WooCommerce PDF Invoices & Packing Slips Premium Templates
WooCommerce
WP Overnight Sidekick
wpSEO

Just another idea: I use a child theme (I guess most other people using such advanced things like varnish do so as well). Would it be possible to have a filter or action to which the array of purged URLs are passed? Then I could just hook into this action and add my “/blog/” and “/shop/” to it, and all is good.

I looked at your code, but I am new to wordpress. Can after_purge_url be used for this?

If not, can you provide such a filter/action? Looking at the documentation maybe a simple little filter like vhp_purge_urls would do. I’d then hook into this with my child theme.

PS I think this approach would also help for other stuff, e.g. to easily allow people to have multi-varnish support if they want. For this you could have a filter like vhp_varnish_ips or similar

Hi,

thanks for getting back.

WordPress Address (URL) is set to: https://www.fiveroasters.de
Site Address (URL) is set to: https://www.fiveroasters.de

Post /a/b/c/ is edited, and then the purge would do this:

Purge /a/b/c/
Purge /a/b/
Purge /a/
Purge /

And we’re back to purging the whole thing. There’s not a great way to detect stop points.

The whole thing? I thought that this would be /.* and not /

The thing is this is the FIRST time I’ve heard of this being a problem. How often are you adding in new products or editing existing ones?

It is not only the /shop but also /blog. I think it is really a problem if I add/edit a product or blog post and it does not show up on /shop or on /blog: User sees new blog or product by means of RSS / Mail / Facebook, goes to this post/product and then to blog overview or shop overview and, peng, the product or blog post is not there.

A workaround might be to purge just everything when something was added, but the “Purge all” button is only available to admins, not to the role “shop manager” (who edit/add products or blog posts at the site)

Sorry, don’t get confused, the last post was from a friend’s computer but it was me ?? Best, Jens

Yes, it seems to be the regex, I tested using curl.

Maybe the logging is really not helpful, because even for the regex Purge I got this reply which basically says “200 Purged” and “Ok: Purged” although it did not work:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>200 Purged.</title>
  </head>
  <body>
    <h1>OK: Purged.</h1>
    <p>Purged.</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>

So I think it is really not necessary to have this logging function because it will not work anyway with varnish… No logging is better than wrong loggin ??

Forget it, I just saw your answer here: https://www.ads-software.com/support/topic/purge-varnish-not-working-saving-postspages-does-purge?replies=3#post-5916708

I’ll try this. Thanks!

I was able to narrow down the issue. Purging for works for:

The front page
The post/page edited
Any categories or tags associated with the page

What does not work is the Purge all button, neither from the admin toolbar nor from the Dashboard. Any idea on this?

Can you give a bit of information so I have some start debugging the issue with my hoster gandi.net? Say, what’s the exact purge command executed for “Purge all” (in contrast to purge an individual page)?

I suspect gandi.net not allowing your purge all command, I’ll try to convince them to allow it but I would need to know what purge command it is that needs to be allowed for this.

I see.

Yes, I think it would be great if there was an “Enable logging” option where all sent commands and results are stored (together with a date) in a specific file, e.g. wp-content/plugins/varnish-http-purge/logs/vhp.log or similar.

If I get it right, then these commands need to be executed on the system where varnish is running?

But I only have access to my Simple Hosting instance. Varnish sits in front of this and I can only “control” it with http (caching headers or PURGE). I have no login for the varnish machine.

There is a small description of how the cache system for gandi.net works at https://wiki.gandi.net/en/simple/cache (afaik other hosters like wpengine or https://pantheon.io/ use the same kind of system)

Seems possible with
https://www.woothemes.com/products/woocommerce-waitlist/
or maybe also with
https://www.woothemes.com/products/advanced-notifications/

Hi Matthias,

thanks for the prompt answer, just a quick response:

2. + 6. ok, I see

7. I am already in live mode. Maybe we’ll just disable 3D Secure with paymill then… Its popup somewhat “irritating”, and irritation is not good for trusty webshops

9. I disagree. I talked to paymill on the phone and they tolded me that they handle the normal Lastschrift (ELV) basically the same like Sparkasse Online Banking is doing it (as in the screenshot): Whenever a user enters just Kontonummer and BLZ, then this is automatically translated to a SEPA-Lastschrift. That is technically there is only SEPA-Lastschrift, however, from a users point of view you only have to enter Kontonr. and BLZ. I think it will be like this for at least the next 5 years, maybe you can clarify with Paymill.

13. ??
Since installing I have this in my www-error.log:
[25-Jan-2015 17:13:15 UTC] PHP Warning: Invalid argument supplied for foreach() in /srv/data/web/vhosts/www.mysite.de/htdocs/wp-content/plugins/paymill/lib/integration/pay_button.inc.php on line 368
[25-Jan-2015 17:41:06 UTC] PHP Warning: Invalid argument supplied for foreach() in /srv/data/web/vhosts/www.mysite.de/htdocs/wp-content/plugins/paymill/lib/integration/pay_button.inc.php on line 368
[25-Jan-2015 17:41:36 UTC] PHP Warning: Invalid argument supplied for foreach() in /srv/data/web/vhosts/www.mysite.de/htdocs/wp-content/plugins/paymill/lib/integration/pay_button.inc.php on line 368