Page / Product edit should purge parent folder like /blog/ or /shop/

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

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).

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).

Also keep in mind, this plugin is trying NOT to flush everything that might possibly be touched. 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.

This page (the one for /shop/) is just empty (it exists as page though), no shortcode in it.

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?

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.

New version is in GitHub as 3.7-beta

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

Sure, except all the people who say it’s too bloated and big ??

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]+”

Except you are. You’re talking about ‘Is this a page? Flush parents. Is this a post? Flush archives.’ That’s what I mean about what might be touched.

Right now I’m not differentiating post-types to keep overhead on that low. Making broad assumptions leads to problems like yours but that’s the intentional tradeoff. You don’t have to flush /blog/page/9/ – the odds of a user actually hitting that page within 2 hours is low.

Flushing the main pages, the main post page, that makes sense. The top level of the archives. Deep diving? EVERY time you publish a post or someone makes a comment?

Maybe.

I do understand and agree with your POV, but it’s something may not make it into this plugin without a structural rewrite to move from the (intended) bare bones simplicity of the plugin into a more middle-road that’s less than W3TC and more than VHP does now. This plugin is a dumb, simple, no option plugin for many reasons.

Hi,

I’ve tested the github version:
1. First, I get the following warning now whenever editing a product or blog post:
PHP Warning: parse_url() expects parameter 1 to be string, array given in /varnish-http-purge/plugin/varnish-http-purge.php on line 139

2. Now /blog/ gets purged but no more /. As you can see on my site (https://www.fiveroasters.de) the blog posts are on the frontpage (/) and on the blog overview (/blog/)

3. “/shop” is still not purged when editing a product.

I’d really like to use your plugin but it is too unflexible and I cannot use it because it results in stale pages (which is a severe error to me!). So I forked it. I only added the aforementioned vhp_purge_urls filter. Here is a pull request. It is just one(!) single line.

With this I can just added this to my child theme and all is fine now:

// add custom / individual purge urls to vhp
function add_purge_urls( $purgeUrls = array() ) {
    $myUrls = array(
        home_url('/'),
        home_url('/shop/'),
        home_url('/blog/'),
        home_url('/blog/page/2'),
        home_url('/blog/page/3'),
        home_url('/blog/page/4')
    );
    $res = array_unique( array_merge( $purgeUrls, $myUrls ) );
    /* error_log( 'FR vhp: ' . print_R($res, true) ); */
    return $res;
}
add_filter( 'vhp_purge_urls', 'add_purge_urls', 10, 1 );

I don’t really like to maintain my own fork of your plugin as this consumes time that I would rather put into something other within the FOSS world… Sadly as it is now, I am foced to do so…

1. I’ll see if I can fix. I didn’t get full testing in (yesterday kicked my a**) though I didn’t get any errors on save, publish, post or flush on my test box.

2. It’s not going to flush the front page if you have ‘use a static front page’ set, under the assumption that it’s static but I’ll have to figure out what to do when people do what you do (it’s the same logic as w3tc – you’re not supposed to have dynamic content on a static front page but I see why people do)

3. Actually accepted the pull request. THAT code is small, clean, and easy to support.

Okay! Found the error. Fixed the error. Made the code better AND put in your filter.

Well. That’s enough for a sick-day, I think.

PostID and postID and PostID are not the same thing.

Thanks for all this! Get well soon!

Thanks for the support, I am setting this thread to resolved now.

Any timeline when this will be released? I know I can update myself with sftp, but just clicking the update button is more convenient (and less error-prone)

Hoping today. Monday is pretty much meetings all day.