Darren Slatten

Plugins like WP Super Cache create the cache files in directories (e.g., /wp-content/cache) that are owned by the user executing the PHP script, so it’s “safe” to allow PHP to delete those cache files.

But Nginx Helper (i.e., the user executing the PHP script) doesn’t actually create/own the cache files; the nginx web server itself does. Nginx Helper is more like an interface to nginx’s native caching functionality. That is, it can trigger the purging of cache files, but it doesn’t delete them directly.

In fact, Nginx Helper shouldn’t even have the necessary user privileges to delete the nginx cache directly, especially in a virtual hosting setup. This is because the cache files are written by nginx to a directory outside of the virtual host’s document root. Allowing Nginx Helper to delete these files would be analogous to a WP plugin that could delete other websites on the same server–it’s possible, but only if the server admin disregards basic security best practices.

The username I enter to log in is Darren Slatten, but in the www.ads-software.com URL it appears as /darren-slatten/. I’m assuming you figured it out though, because I updated to the latest version and the changelog link to my profile is working. Thanks for the recognition.

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.

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

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?

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.

I found a similar bug.

Version: 1.6.15.2
File: aioseop.class.php
Error:

Notice: Undefined index: aiosp_front_meta_tags in /wp-content/plugins/all-in-one-seo-pack/aioseop.class.php on line 2382

The fix could be to change line 346 from this:

$front_meta = stripcslashes($aioseop_options['aiosp_front_meta_tags']);

to this:

$front_meta = isset($aioseop_options['aiosp_front_meta_tags']) ? '' : stripcslashes($aioseop_options['aiosp_front_meta_tags']);

The frustrating part about this particular bug is that the error notice HTML code got printed into the “Additional Front Page Headers:” textarea on the options page. Normally, this HTML would render as a big, ugly, orange-headed table, but since it was wrapped in the textarea tags, it rendered as an inconspicuous block of editable plain text. So when I updated the options, I didn’t notice that this textarea field had been populated with the error notice’s raw HTML, and I essentially saved the error notice HTML as an “Additional Front Page Header”. Then when I viewed the home page, I saw the big orange error notice–despite the fact that PHP loaded the page without any errors. The error notice code was simply being retrieved from $aioseop_options['aiosp_front_meta_tags'] and inserted into the head section.

Good times.

Then why drag the Suffusion Theme into the conversation? If it has nothing to do with Suffusion directly, then you’ve only served to spread FUD about a very conscientious Theme developer.

Actually, I think Sayontan Sinha responded admirably, and if anything, I’m now more inclined to use Suffusion because I’ve witnessed firsthand how conscientious he is.

WordPress doesn’t have 3.x versions. In WordPress, major versions are “X.Y”. Thus, 3.3, 3.2, and 3.1 are just as much major versions as 3.0 – and referring to “WordPress 3” or “WordPress 3.X” is semantically meaningless.

Surely someone with such strongly held convictions regarding the development architecture of WordPress understands something as basic as the WordPress versioning nomenclature?

Translation:

Despite the existence of well-established software versioning conventions, WordPress has decided to reinvent that wheel, and the wheel they’ve chosen…is actually a cube. (One of the core developers used to babysit for a family that had a cat named Cube, so naturally, it was the only logical choice.)

Since fireproofsocks believes that wheels should be round, he obviously doesn’t understand WordPress, and any ideas he has about moving it forward are probably bad ones.

===========================

Nicely done, Chip. I’m pretty sure that’s a guaranteed win for you in this round. Let’s go to our panel of totally-unbiased judge and see how they scored this one. …Nacin?

Darren Slatten lost an argument regarding the appropriate use of output buffering in Themes, and is still upset about it.

I don’t think anyone won/lost that argument, Chip. But you’re right about me being upset by it though. It was rather disturbing to realize that WordPress is basically one big patchwork of bad ideas, unchecked opinions, and a long legacy of arbitrary decisions made by a “team” of developers whose only shared vision of WordPress’s future is one in which they are right and everyone else is wrong.

fireproofsocks,

Before you invest too much time and energy exploring the theme-reviewers mailing list as a potential vehicle for “changing the course”, I strongly encourage you to spend a few minutes reading some of the past discussions that have taken place there. Here are a few of my own personal favorites:

https://lists.www.ads-software.com/pipermail/theme-reviewers/2011-July/006128.html
https://lists.www.ads-software.com/pipermail/theme-reviewers/2011-July/006176.html
https://lists.www.ads-software.com/pipermail/theme-reviewers/2011-July/006182.html

TLDR: The mailing list is a waste of time unless your only goal is to gain insight into how/why the WP theme/plugin system got so thoroughly effed in the first place. If your goal is to initiate changes that will un[expletive deleted] WordPress at an architectural level, you’ll quickly realize that WordPress is 100% open-source, 0% open-minded.

If WordPress is the 8th grader of CMSs, then the theme-reviewers mailing list is the comment stream on that 8th grader’s MySpace profile.