Who would have guessed that automatically correcting the use of WordPress within the post title and content areas would cause such a flurry of activity. I’ll try to summarize the points of discussion up to this point.
In WordPress 3.0, folks can no longer incorrectly misspell WordPress with a lower case p (WordPress). This use is detected by the following patch (14996) that Matt Mullenweg wrote and was then committed by Andrew Nacin. The code simply adds a filter that looks for WordPress used with a lower case p within the content, the post title, and comment text. If detected, the word is replace by the correct spelling. It’s a very simple patch but its simplicity has met strong resistance from those in the developer circle.
One of the arguments against this patch deals with performance which is discussed earlier on in the comments within ticket 13971.
Then there is the principle of the matter. Should WordPress force the use of a word without consent or recourse? Quite a few people don’t think so. By the way, I’ve seen some people comparing this behaviour to how the iPhone spell checker works. This is an incorrect comparison because the iPhone spellchecker provides an option to use the correct spelling or not. WordPress does not. It automatically uses the correct spelling whether you like it or not, at least when you’re using a lower case p. This is a distinct difference between the two.
Although a minor inconvenience, some of us will be made to look foolish thanks to the auto correction. Those who are well versed in the WordPress community understand the proper spelling. Occasionally, we would write posts to try and inform the masses on how to properly spell the word. In fact, there are a few plugins in existence that performed the same function as this patch, such as the one created by Ozh in 2007. As you can read in his post, the lower case p versions of the word are corrected which is not only confusing since we don’t know what is being corrected, but it generally makes the entire post look like an April Fools joke.
There are also instances in which the patch breaks things as per ticket 13971 where an image file name with a lower case p was automatically changed to a capital P thus breaking the image.
It’s also worth mentioning that Matt did not bypass everyone and put the patch into WordPress. In fact, the idea was run past the other lead developers for WordPress as per Mark Jaquith:
This was run past the other leads. I brought up the argument that this might break a great many links. Matt said that they’d been running it on WordPress.com for several years with, I believe, only one recorded instance of it breaking anything. That satisfied me that this reported bug would occur infrequently.
I understand WordPress.com is a huge testbed for WordPress.org code, but you can not use WordPress.com in nearly as many ways as the WordPress.org software. WordPress.com users can’t use plugins so how would you ever know if plugins, especially image gallery ones would work with this change?
Removing The Functionality:
If the change has broken your site or you don’t like WordPress being changed automatically to the correct spelling, you can use the following plugin that will remove the filter. I’ve installed this plugin on WPTavern.com as a means of supporting its removal.
Where I Stand:
I’ve had nothing break, that I know of due to the forced spelling change. In fact, I’ve found it very convenient but after giving the principles of the matter more thought and looking at the bigger picture, I don’t think WordPress should be forcing anything upon its users, especially when it comes to content. If people want to misspell something, let them do that. Don’t hold their hand and change their content for them without recourse. I would have used this opportunity to promote the After The Deadline plugin/service as it correctly labels the misspelling of WordPress. I also would have used PollDaddy to generate a poll to get a feel for what others thought about the idea and possible repercussions on the proposed implementation.
While a handful of developers have chimed in with their support of reverting the patch from the core of WordPress, Matt’s responses within the WP-Hackers mailing list thread regarding the issue give a sense of the change not going anywhere and sticking to his guns although he admits that if people voted with their feet or via a plugin to disable/remove the filter, he would reconsider:
As I said before, you are in /complete control/ of your site. It’s a single line to remove a filter. If you don’t like the filter, vote with your feet or with a plugin. If the function cause a non-trivial number of people to avoid 3.0, leave WP, or install a plugin to deactivate I would seriously reconsider it. In the absence of that, there are a 1,001 better places to focus my attention with regards to WordPress.
The patch has good intentions but this addition to WordPress is one more example of something that needed a wider scope of feedback before being implemented into the core. I’d like to see the auto correcting behaviour removed until it’s decided that according to the community, they have no problem with it. In fact, I bet if a poll was conducted via the WordPress Dev blog or even Matt’s blog explaining the patch, its intentions, and possible pitfalls, the response would have been more positive than negative and if it were voted to be included or most people didn’t care, then a bunch of energy wouldn’t have been spent fighting against it.
Speaking of communication, it may also be worth noting that Matt’s patch did not have a ticket attached to it to provide discussion from other developers before it was committed. It was a straight patch. If I’m wrong on this point, please provide a link in the comments to the ticket before the patch was committed.
P.S. For a good laugh, check out WPCamelcase.com.