bigsite

Unfortunately, after a mere 12 hours of testing in production, this plugin also appears to suffer from random RSS feeds being served up plus offers the brand new additional benefit of serving up totally random content from other blogs onto the homepage (something WP Super Cache doesn’t seem to do).

So, Lite-Cache (v2.2.7) is no better than WP Super Cache (v1.3.2) and only mildly better than W3 Total Disaster Cache (v0.9.3).

Caching plugins shouldn’t exist nor be necessary because WP should be doing caching natively (and doing it well).

For reference, these random issues only occur when the system is under consistently heavy load and only in conjunction with multisite, an opcode cache, and a WP caching plugin. And this problem has been occurring for YEARS across multiple software and hardware configurations to rule out all possibilities. The hardware itself is fine (all memory and drive tests pass, drives are in a rational RAID configuration, and has a fairly recent quad-core Xeon). We even swapped all the hardware at one point! All the software is kept up-to-date (latest Apache, latest PHP, latest WP, etc). The plugins are minimal and vetted, a couple are custom-built, but I know what I’m doing there – and I’m a heck of a lot better at writing WP plugins than most people writing them because I HAVE to target multisite. So it boils down to caching plugins and bugs in WP. There is a bug in WP, I just have no idea where because the problem only shows up under specific circumstances which I’ve mostly narrowed down to a fairly specific combination of software. The fact that I now have proof that the same bug spans multiple caching plugins means that caching plugins can be ruled out and that the problem is in the core of WP itself! It isn’t hardware, it isn’t the server software, it isn’t the caching plugin(s) out there, it is WordPress.

WP Super Cache attempts to counter the random page homepage issue – the author knows about it outside of our own specific encounters with the bug! The author of WP Super Cache is attempting to work around a nearly untraceable bug in WP. This is further proof that there is a bug in WP itself that causes caching plugins to malfunction. No other PHP-based software product I use has the problem of serving up completely incorrect content, which only adds more proof that the problem is in WordPress itself.

Okay WordPress devs…the ball is finally in your court!

Wireshark confirms that this is the same issue that I’ve previously experienced. I think I’ve got enough data now to go to the web server folks and say, “Hey, your product seems a bit broken.” We’ll see how much trickles down to WP itself.

We’ve had this issue for almost a year. No one on these forums has been able to help us. Our main problem has been reliably reproducing the issue. We also get distorted dashboards and pages. Today I was notified of a blog where the issue is 100% reproducible but only happens when creating or updating a post and I’ve verified the problem. FYI, all the other blogs are acting about as “normal” as they usually do. This is perfect because I have an opportunity to pinpoint this bug’s source and get it fixed. The technology stack setup is “weird”, so it could be anywhere – but being able to reliably replicate the issue is a step in the right direction. Regardless, it is good to know that other people are experiencing our issues on live, production systems.

The last time I was able to “mostly” reliably reproduce the issue (about 50% of the time), I hooked up Wireshark and discovered that the connection simply dropped without any reply from the server. Nor did the server have any logs. This might be something new or more of the same. But 100% reliability of the core problem has never happened before today.

Our technology stack: nginx + php-fpm + PHP opcode cache + WP Super Cache running on a Intel (Xeon) Mac OSX Leopard Server.

Multiple issues: A symlink on a modern filesystem isn’t a file. The directory tree a symlink points to isn’t meant to be walked during a tree delete. Calling the directory ‘/cache/’ makes it look like it is a general place to store cached content for any plugin – NOTHING about the name says that it is ONLY for ‘wp-super-cache’ content. In my case, I recreate the symlinks every few minutes if they get deleted.

WordPress, on our installation, also has a nasty habit of creating a (broken) symlink instead of a directory when setting up a new site, which I have to manually fix from the command-line. I strongly suspect this is due to our PHP opcode cache. It is conceivable that this plugin with a PHP opcode cache could create a working symlink that later causes severe data loss.

Or let’s suppose someone manages to somehow set up a symlink somewhere in the cache directory tree. If the admin later disables this plugin there will be severe data loss.

The simple fix is to use ‘is_link()’ before traversing into what looks like a directory. The real fix is to stop deleting files on deactivation.

I fixed my code by doing:

https://pastebin.com/L2Bv7sen

Accessing the database directly is SO much cleaner than trying to parse an object that could change between versions. I realize user levels are “deprecated”, but the devs directly admit that user levels vs. capabilities are “a mess”:

https://core.trac.www.ads-software.com/ticket/16841

User levels are still quite useful for answering the question, “Does the user have ANY permissions?” That is a true/false answer so any non-zero value is fine by me. But the above function could be useful for someone stuck in the past with an old code base.

Same/similar problem here. I haven’t really dug into the issue a whole lot but it looks like it might have to do with newlines for us – we aren’t seeing any new paragraphs in the imported comments where there used to be. All comments are UTF-8 too, so it shouldn’t be a character set issue on our end.

Well-behaved programs on *NIX systems don’t blindly traverse every directory while deleting files. Determining the difference between a symbolic link and a real directory is easy.

WP Super Cache is already directly responsible for causing data loss.

More importantly, I read your reply to mean that you aren’t interested in preventing future data loss from happening.

I see your stance on actual data loss as horribly wrong. If I learned that my software caused data loss, I would bend over backwards to make sure it never happened again.

“Why would you create a symlink in a “cache” directory to files like that? The cache directory is generally for temporary files.”

Because WP multisite installs resolve file URLs by invoking WordPress, reverse-engineering the permalink, locating the file, and then serving it up. This file serving tactic doesn’t happen with single blog installs, just multisite installs. The symlink approach allow for blog names to resolve cleanly to their internal numeric value and using a simple rewrite rule to point at the correct location. The symlinks themselves are the “cached/temporary” items, not the files/directories they link to. This approach makes perfect sense to me.

If you feel you must delete files and directories on deactivation, please at least make a call to the PHP function is_link() and only remove the link so that you don’t just blindly walk every directory deleting everything willy-nilly. The result will still be annoying but will be MUCH less painful.

@esmi – “I couldn’t care less what you authored.” ?? Took me a month to build that ruleset and it has helped all sorts of people so reading that made me sad. How about we now just call it even? I was mean. And you were mean. I’ll try to do better in the future – that’s all I can offer. I’ll also try to not have a migraine too when I post (migraines make me rather irritable).

The idea here is to call url_to_internal_info($url) with the permalink and you get back an array of ‘blog_id’, ‘type’, and ‘type_id’. Usually ‘type’ will be ‘post’ and ‘type_id’ will be the post ID, but not always (you know how WP is ??

@duck__boy – “probably not worth it”. I wouldn’t be asking if it wasn’t worth it.

@esmi – I just knew someone would drop in and be completely unhelpful. Congratulations, you’re “that person”.

I know WP pretty well as well as being an expert PHP developer, so I wouldn’t be asking if I didn’t need such functionality. I am more than capable of hacking something together, but what I want to know is what the “CORRECT” way of doing what I want to do? There’s always the hacky way and then there is right way.

Since my post 35-ish minutes ago, I’ve scoured the WP codebase and have come across:

url_to_postid() – requires switch_to_blog() and restore_current_blog() calls, but I’m used to doing that extensively already.

get_id_from_blogname()
get_blog_details()
get_blog_id_from_url() – which is rather misleading as to what it does.

I’ve got a few ideas but this is hardly ideal.

Edit: BTW, I already have the permalinks I’m looking to reverse engineer. So, the $_SERVER[] recommendation is equally useless.

Edit #2: Unless you are an expert PHP and WP web developer who has used WP multisite _extensively_, then please don’t reply.

@per Hansson – Your configuration is really screwy. Most obvious problem is that you can’t have ‘try_files’ and ‘if’/’rewrite’ in the same ‘location’ block. They are two separate modules that can’t be mixed. See the official ‘IfIsEvil’ Nginx documentation, which barely covers this rather critical topic.

@dan Collis-Puro – I understand that and use that combination on personal servers without any issues. We definitely tried Apache + PHP + PHP APC first, but there were some really bizarre things going on with that combination on our specific setup. Turning off PHP APC resolved the issues, turning it back on resulted in the issues coming back. So, by process of elimination, PHP APC was definitely the cause. Switching to nginx and php-fpm is the only way we’ve found that allows us to run PHP APC without nearly as many issues on our specific setup. We still get the occasional hiccup but it isn’t nearly as bad as it was and we’re relatively happy at the moment.

@dan Collis-Puro – Unfortunately it is not possible to do that here. Running Apache would require us to eliminate PHP APC. Also, a number of custom plugins would break. nginx works fine and, really, that part of the setup is a lot simpler than you might think – especially since the creation of the nginx configuration entry in the Codex based heavily on this thread.

Let me know when your code is in the latest devel download and we’ll give it a go in our production environment. We’re using a hack (cron job) at the moment, that I’d love to get rid of, that completely wipes all files in the cache every fifteen minutes.