Feature Suggestion for Additional Purge Options

Correct me if I’m wrong, but it looks to me like the plugin is already using that approach (looping through all the URLs whether they are cached or not), it just limits itself to certain classes of URLs (e.g., home, archives, posts, pages, etc.), depending on the WP action that initiated the purge.

For the Purge Everything button, I was envisioning a simple function that calls each of the purge functions (or methods, rather) in succession. In fact, when I was looking at purger.php, I noticed there’s a method that seems to do exactly what I was hoping for:

private function _purge_them_all() {
    $this->log( __( "LET'S PURGE ALL THE BLOG.", "rt_wp_nginx_helper" ) );
    $this->_purge_homepage();
    $this->_purge_personal_urls();
    $this->_purge_all_posts();
    $this->_purge_all_taxonomies();
    $this->_purge_all_date_archives();
    return true;
}

But I couldn’t find _purge_them_all mentioned anywhere else in the code. So…I guess my question is: besides the inelegance aspect, is there another reason why this wasn’t made available to users? For example, does it cause significant performance issues at a certain point?

I’ve only recently started using the fastcgi_cache directives, but as far as I know, there’s no way to define separate cache paths for each server block. Right now, I can easily empty the cache because I only have one domain using it, so I just delete everything in the folder (via command line). But as I start to configure more domains to use the cache, it won’t be that simple (unless I just delete the cache for all domains every time one of them changes). The way I see it, using something like _purge_them_all might be the only solution available to me.

Regarding ideas for a better approach, nothing really comes to mind. The only alternative I can think of would be to loop through the cache directories/files themselves, read the content, parse out the KEY: httpGETwww.example.com/example-uri strings, and build a list of cached URLs, which you could then send to /purge.

One problem with reading the cache directly is that the files are owned by the server, so I’m not even sure if PHP can read them on the average nginx setup, without users changing the permissions first. Even if they could, I don’t see how this would be any better/faster than blindly sending all WP URLs to /purge.

Yeah, nevermind that idea. I just talked myself out of it. LOL.

Anyway, please let me know what’s up with _purge_them_all, because I’m really tempted to hook it into something.

Thanks.

Okay, I’ll take a stab at it. I’ll probably just go with the manual button approach, to reduce the likelihood of users automatically triggering it without understanding the impact.

I do have one question though…

In your recommended site configuration, you disable the caching of /feed/ URLs:

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $no_cache 1;
}

But then I noticed in my nginx-helper/nginx.log file that the /feed/ variation of all URLs is also sent to /purge/. Seems to me if no one is caching /feed/ files to begin with, then I’d be able to remove them from the purge process, and thus reduce the number of uncached URLs sent to /purge/ by as much as 50%.

So the question is: should I disable the purging of /feed/ URLs or leave it alone?

Okay, I just sent a pull request for the “Purge Everything” functionality. I didn’t make any changes to the /feed/ links (yet). The only other minor change I made was to add a space between the top checkboxes and their labels (on the settings page). The nonconformity was killing me. 😉

That’s weird. I went to the URL you provided for tag 1.6.5 and forked it. If it didn’t work, then…I guess I don’t know how to fork a repo according to a specific tag.

But if I understand you correctly, you made adjustments so that I don’t need to use the tag. In other words, I’ll just repeat the same process I used last time…but this time it should work.