Three Unsolved WordPress Mysteries

By Jeff Starr on Tuesday, April 8, 2008 — 22 Responses metadata

Post #527 categorized as WordPress, last updated on Apr 13, 2008
Tagged with errors, htaccess, http, log, php, plugins, WordPress

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

Subscribe to Perishable Press

Toggle Post Options 22777 visits