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 403 “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:
.htaccessLynxSource
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..
21 responses to “Three Unsolved WordPress Mysteries”
Re #3: Can’t believe no one bothered to look at the history of the page. No offense but that’s the first thing people should have done. It was removed by Lorelle.
Perishable@9: I went for the mid-tier application hosting (shared) package to begin with; I don’t need a dedicated server. I basically read the webhostingtalk forums for a month and tried all the most commonly recommended hosts for my needs, and ML was the best.
You could try out an AppLayer for a month and see if it suits you, they don’t charge big setup fees or anything.
Btw I’m getting no kickback/affiliation deal from ML, just a very happy customer so far. ;)
@Dr. Mike Wendell: Yes, the decision to remove the plugin pages was discussed by Stephen Cronin in this article (linked to in the post above as well). Although this information is useful, it doesn’t justify the decision itself. The point that I try to make in the article is that the decision to remove the plugin pages was a bad one. Those pages were so useful, complete, easy to use, edit, and update, that it just seems pointless to replace them with a system that is far too tedious and time-consuming. In my opinion, the decision to remove the pages was thoughtless and even insulting to all of the many, many freely contributing developers out there who no longer enjoy the benefits of the dropped pages.
@Steven: I’m sold! I will definitely be giving MediaLayer a try as soon as the opportunity arises.
I assume the shared hosting (AppLayer) is reasonably priced?Edit: oops! My bad — I see they have the prices listed right there alongside the packages.. seems very competitive..Tried vpslink ?
(btw you should mention somewhere that you’re going naked CSS. I hit refresh like ten times wondering why my browser wouldnt load the CSS. Tell your readers why it’s so ugly :)
No, have you? What’s the word on vpslink? Reliable? Consistent? Support? What’s up! And what, you don’t dig the “naked” look? Nothing to be ashamed of, right? Hell, I’m naked right now! ;)
I’ve heard good feedback from folks in #wordpress (namely ioerror if I remember). Prices are very affordable. Note that I’m a strong believer of the “There is no good host” theory. The thing is just to find the least crappy one (given that “good” is always relative to the amount of money you’re willing to put in it)
So true about the “good host” theory — if only I could afford more than the average fare! In any case, I appreciate the tip and will check it out in depth during the next, ultimately inevitable round of extreme shared-hosting frustration!
I don’t get how the WordPress team is all head over heels about Subversion, when
Linus T. says Git is the way to go.
http://www.google.com/search?q=git+linus+subversion
http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html