Latest TweetsVerify any search engine or visitor via CLI Forward-Reverse Lookup perishablepress.com/cli-forwar…
Perishable Press

Three Unsolved WordPress Mysteries

After several years of using WordPress, I have at least three unanswered questions:

  • What’s up with the WordPress PHP Memory Error?
  • Why do certain phrases trigger “Forbidden” errors when saving or publishing posts?
  • What happened to the Plugin Pages in the WordPress Codex?

Let’s have a look at each one of these baffling mysteries..

Unsolved Mystery #1: What’s up with the WordPress PHP Memory Error?

Every single day, WordPress generates hundreds of these errors:

[20-Feb-2008 19:49:42] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6316713 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:50:51] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6304873 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:52:20] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6337545 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:52:34] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6269893 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:53:03] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6328897 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:55:26] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6342189 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:56:54] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6328897 bytes) in /home/.../press/wp-includes/cache.php on line 330
[20-Feb-2008 19:57:29] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 6330933 bytes) in /home/.../press/wp-includes/cache.php on line 330
.
.
.
[ + plus hundreds more every day.. (see file link below) ]

To really get a glimpse of the seriousness and frequency of this error, check out this excerpt from a daily PHP error log.

I have addressed this error before, both posing the question and providing a solution, however, the solution is merely a workaround until the underlying issue is resolved. Further, the temporary fix is limited in that it only works on certain server setups. For example, the fix is ineffective and the cache error remains here on A Small Orange servers.

So, I ask the question again, yet with more emphasis and urgency this time: “What’s up with this relentless WordPress PHP cache error?” Surely, somebody out there has some insights, ideas, or inspiration concerning this very problematic issue. Full article treatment to anyone who discovers a solution that works for everyone.

Unsolved Mystery #2: Why do certain phrases trigger “403? — Forbidden” errors when saving or publishing posts?

In a recent article on the WordPress Autosave feature, I mentioned a scenario in which certain words and phrases trigger 403 errors when saving or publishing posts. For apparently no reason whatsoever, inclusion of specific phrases, words, and/or character strings in post content results in the swift return of a 403 - Forbidden error as soon as the “Save” or “Publish” button is activated.

Apart from being quite annoying, these unexpected errors somehow trip up the autosave process, causing the autosave function to fail and countless hours of work to be lost completely. Two examples of these mysterious, unutterable phrases are:

  • .htaccess
  • Lynx Source

To include these phrases in this post, I had to split them up with <code> elements and insert &nbsp; in between the two words in the second example. Not that I need to use these specific phrases in every post, but as my readers know, I tend to cover htaccess quite a bit. Although these workarounds are simple enough, it would be good to finally resolve this long-standing issue.

Further, in my experience, there are other character strings that trigger the 403 errors, but I have not yet had the time (or patience) to isolate and identify them. If nothing else, perhaps this information will help WordPress users diagnose unexpected post-publishing errors of their own. What is causing this issue? Have you experienced anything similar? Any ideas..?

Unsolved Mystery #3: What happened to the Plugin Pages in the WordPress Codex?

Whoever decided to remove the original WordPress plugin pages (previously located at: http://codex.wordpress.org/Plugins/) should be slapped upside the head. Those pages were well-known, well-linked, and frequently used by the WordPress community. Users enjoyed access to a “complete” collection of plugin functionality, while plugin developers — who freely contribute time, effort, and resources to the WordPress community — enjoyed the sheer simplicity of posting and updating their projects quickly and easily.

Now that the pages have been suddenly and quietly deleted, the link equity that once flowed to developer plugin pages has vanished. What a nice way to say “thanks” to all the folks who have helped to make WordPress the great piece of software it is today.

As an alternative to the orignal plugin archive, we now have an official plugin repository. Unfortunately, the process of adding, updating, and/or editing your plugins consumes a great deal of time, especially if you are unfamiliar with the convoluted protocol required for participation.

Further, assuming you are patient and forgiving (or desperate) enough to endure the routine of including and updating your plugins, the new policy requires that you permit WordPress.org to distribute your plugins directly from their domain. Yes, you may provide a link to the plugin home page, but even so, many visitors will simply grab the plugin directly from the Codex and completely ignore your site (unless, of course, they need help figuring something out). In this way, the new plugin repository system removes a powerful incentive for future plugin developers: traffic, exposure, and recognition for their work is now funneled directly to WordPress.org.

So, to sum up, the classic WordPress plugin directory:

  • Made it super easy to add and update plugin information
  • Required less time, less effort, and fewer resources
  • Was well-organized, well-known, and easy to use
  • Passed attention and recognition to developers
  • Delivered all traffic directly to plugin sites
  • Made it easy to shop for and compare plugins
  • Served as a more complete plugin directory
  • Ranked well among search engines (high PR)

..which contrasts with the new WordPress plugin repository:

  • Consumes waay too much time and effort
  • Complicates the process of adding/updating plugins
  • Makes it impossible to compare plugins side by side
  • Is tediously organized, convoluted, and overwrought
  • Steals attention and recognition from developers
  • Steals key traffic from plugin developer sites
  • Remains less complete than the original archive
  • Sterilizes individualism with pointless uniformity

Unfortunately, my voice is far too small to resurrect the original plugin pages, but it sure feels good to open up and actually “vent” about something. Admittedly, venting as such is something that I generally try to avoid like the plague, but in this case I just couldn’t help myself. Hopefully, now that I have finished voicing my concerns, the issue has been addressed and I may move ahead with the business at hand..

Jeff Starr
About the Author Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.
Archives
21 responses
  1. Josh Byers April 8, 2008 @ 1:59 pm

    I couldn’t agree more about the plugin rant. I am a beginner plugin developer and it would be great to have those old pages back.

    I have tried in vain on both a mac and win system to get subversion running to add my plugin to the database – but I guess I’m not smart enough. It someone could point me to a comprehensive rundown on how this works, that would be great…

  2. +1 to all of the above — plus mystery #4 (if you’re so inclined): what happened to the Codex Theme list? With the official theme viewer languishing as it is, it didn’t seem reasonable to remove the only area where theme creators could keep their users up to date on the status of themes.

  3. #1: I’d say this is gone with WP 2.5, or isn’t it ?
    #2: are you using mod_security on this server?
    #3: answer is here

  4. As others have said, it sounds like something in your specific hosting config: I’ve never seen these errors.

    Btw, if you’re still looking for alternative hosting, I no longer recommend MediaTemple (the grid has been appalling recently). After trialling lots of other hosts, I settled on MediaLayer, who offer hosting specifically tuned for php/MySQL applications. It is blazing fast and the support is amazing. :)

  5. Similarly to Ozh, mod_security is the first thing that jumped to mind when you described your problem. One of the main things it does is filter data sent via POST, which of course includes anything you submit via WordPress. Various hosts use different configurations which catch more or less false positives than others, but the general point is to prevent XSS exploits, etc.

    mod_security isn’t the only server software that does this kind of thing though, so an absence of mod_security doesn’t mean much. Also check that your host doesn’t use SUHOSIN, and there’re some others out there too.

    I had a problem with phpBB myself where the server would just return an error when I tried to modify my gigantic phpBB CSS file through the admin area. Eventually I realised that it wasn’t mod_security/SUHOSIN’S filtering after all, but instead a character limit SUHOSIN applies to POST submissions. Getting my host to double the limit solved it.

    In short, I’m willing to confidently say it’s your server software. Security software like this is good, but can bring out all sorts of unexpected and obscure application issues.

  6. I came here to write the exact answers as Ozh. Spooky.

    You seem to be using WordPress 2.3.3, so I think once you upgrade to 2.5, #1 will disappear.

  7. Jeff Starr

    @Ozh: Not sure (yet) about the effect of WordPress 2.5 in regards to the memory issue. Will report later after finding time for the upgrade. In the meantime, I did manage to implement running PHP 5 along with PHP 4 on my server, and that seems to have a positive effect, but more testing is required before I can confirm anything. As for mod_security — yes, it is enabled, and I will be investigating further to see if that is indeed the culprit (it does make sense). And, for your answer to mystery #3: no comment (but thanks for pointing it out;).

  8. Jeff Starr

    @Ryan: Yes, I seem to agree that mod_security (or some other server software) is probably responsible for the blocked character strings. Now I want to see the filtering rules that are used to determine “forbidden” phrases (would make for a great post)! Also, thanks for the heads up on SUHOSIN character limits. It’s not running on this server, but your descriptions make me wonder about a similar issue on a different server. Great info, again, thanks!

  9. Jeff Starr

    @Steven: Yes, I am always on the lookout for better hosting. I have yet to find a host that isn’t lacking in at least one department. I have tried Media Temple, WiredTree, and a host (no pun intended) of others. I am currently back on shared hosting plan at A Small Orange and have to admit that customer support (one of their primary selling points) has been less than stellar as of late. Plus, lots of downtime, frustration, etc. In short, I would love to find that “perfect” host and switch immediately. Your recommendation of MediaLayer looks very good. Did you go for dedicated or application hosting, btw?

  10. Jeff Starr

    @filosofo: Looks like I have no choice and will be upgrading to WP 2.5 after all! Btw, it is great to see you here, filosofo — thanks for dropping by! :)

  11. Jeff Starr

    @Josh: Once I find time to jump through the hoops and get my plugins listed (assuming they’ll still have me!), I will write an in-depth article that explains the entire process of adding/editing plugins at the new database (assuming I am able to figure it out). In the meantime, this article seems fairly comprhensive, and may provide the info you need to get started. Good luck!

  12. Jeff Starr

    @WP Diva: Certainly this has something to do with the mad rush to subversion for both plugins and themes. On the theme viewer page, they provide the following information:

    Just wanted to do a quick update for those wondering when you’ll be able to add new themes or update existing ones here in the directory. We’ve been working very hard on a new Subversion-backed database for themes that will allow you to upload themes as you did before, as a plain ZIP file, and we’re transparently check it into SVN so changes can be tracked just like we do for WordPress development.

    If they did remove the Codex Themes list, I am not surprised. Apparently, it’s just too simple to allow freely contributing plugin and theme developers to keep their information updated quickly and easily. There must be a better way!

[ Comments are closed for this post ]