Justin Tadlock

Lowercase p, dangit!

If you haven’t been following the latest hot debate in the WordPress community, you’re in for some news. If you have been following it, you’re probably in a fiery rage, given up all hope in the “community” aspect of this community project, or are just sitting back laughing at the rest of us.

The issue: Before WordPress 3.0 was released, a small piece of code was added to the WordPress core that changes all instances of “Wordpress” (notice the lowercase “p”) to “WordPress” in areas where content is shown on the site. We’ll get to the details in a bit.

I tried hard to stay out this debate because I’m fairly certain I made a vow to myself to stay out of these types of arguments. But, I’ve got a few opinions on this one that I can’t just keep to myself. And, as someone that is considered a leader within the WordPress community, I feel responsible for communicating with that community on this issue.

It’s spelled “WordPress”

WPCamelCase.com (site no longer available) says so, and I’d never question an entire site dedicated to the proper spelling of a single word.

On a more serious note, these are not proper:

  • Wordpress
  • wordPress
  • wordpress
  • Word Press
  • word press
  • wordress
  • WoRdPrEsS

Coming from an English and journalism (especially journalism) background, I feel a strong need to hack into the site of anyone that misspells WordPress and correct it for them. Fortunately, I don’t know how to hack people’s sites, have just a smidgen of self control, and respect the rights of others.

Why is there an issue?

Matt Mullenweg wrote a filter function called capital_P_dangit() that correctly capitalizes the “P” in misspellings of WordPress where the “p” is lowercase. It may seem like a minor thing, but there are several issues at hand.

  • The code literally breaks things like URLs on some sites. For example, suppose you installed WordPress in a /Wordpress directory. That would cause all kinds of trouble with things like images.
  • This function is effectively changing what people write, and WordPress should not have editorial control over the content of anyone’s blog.
  • The code was committed to WordPress without a Trac ticket, so it wasn’t left open to community discussion beforehand.
  • Matt’s responses seem to dismiss the very community of people that help make WordPress what it is.

Following the discussion

I cannot accurately represent all of the discussion that has happened to this point. I highly recommend that you read the discussions provided by the below links if you want all the details.

Breaking URLs

If nothing else, this issue must be addressed. In fact, this bug was brought up in a bug report before WordPress 3.0 was released. Yes, before.

The resolution set for this bug: wontfix.

A new ticket is now open for discussion and resolutions. Mark Jaquith has at least created a patch that should fix this issue.

Don’t change my content

The real issue is not the bug; it’s the display of content that people didn’t write. Sure, the cases where people actually intend to misspell WordPress are rare, but that’s besides the point.

The point is that the content is yours, and you should be able to write anything any way you see fit, including “WordPress.”

If you want to debate that last statement in any way, I suppose you can try all you want, but I can’t think of a single reason why a piece of software should be able to control the output of my words without consent.

We’re talking about principles here, and changing what people write in this manner goes against everything I believe in. I simply refuse to allow this on my site.

One of the reasons I use WordPress is because of its philosophy on community, openness, and freedom, which fits along nicely with my own personal philosophy about most things in life. The idea that a piece of software could infringe upon those values is what bothers people.

What about emoticons and auto-paragraphs?

What about apples and oranges?

This line of reasoning keeps getting brought up in the debate.

If you think the forced spelling of a word and the opt-in process of converting smileys and basic word-processing are one in the same, there’s no convincing you there’s an issue. You may as well stop reading now.

Why don’t you build a plugin?

According to Matt Mullenweg, a plugin should be built:

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.

Vote with your feet? This type of remark represents one of the biggest issues in the WordPress community. Attitudes like this can bring down entire empires.

I completely agree with the plugin idea though. Building plugins to gauge community interest in certain features and making the decision to include these plugins in core code based on statistics is a great idea.

As pointed out by Jeff Chander, it just so happens that someone made a plugin nearly three years ago that does the same job as capital_P_dangit(). It’s called Ozh’ Correctly Spell WordPress.

At the time of writing, this plugin has received a grand total of…wait for it…338 downloads!

As flawed as that argument is, a new plugin has been created called Remove Wordpress to WordPress Filter that disables the capital_P_dangit() functionality. Funnily enough, its number of downloads will likely surpass the other plugin within a week or two given its current rate of adoption.

But, since we’re voting with plugins, there’ll be 16 other plugins that will disable this filter soon enough. All of my plugins will have this bug fix added to them in their next updates.

There’s two things that will make me reconsider this decision and remove this from my plugins:

  • The capital_P_dangit() function is removed from the default filters or made to be opt-in.
  • An outcry of arguments from my plugin users to remove it. Some of us listen to our users, even when we disagree with them.

Since some folks have missed the point of this last argument, which I thought was clever (though I’m a bit biased), I must inject a note here to interrupt the flow of this article. No, I don’t actually intend to update all 16 of my plugins to try and prove a point. The entire point is to show how irrational such an action would be.

How to remove the capital_P_dangit() filter

You can either install the Remove Wordpress to WordPress Filter plugin or add the below code to your theme’s functions.php file.

remove_filter( 'the_title', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'comment_text', 'capital_P_dangit', 31 );

Listen to your community

I’ve only seen a handful of people that agree this function should be in WordPress. It has been met with harsh opposition. The people arguing to remove this function are people we need in the community. They’re plugin developers, theme developers, contributors to core code, and evangelists for the WordPress platform. These are the people that continue making WordPress better.

Don’t alienate them.

Are these people only a vocal minority of WordPress users? Certainly. However, these people speak for a larger amount of users. For users without the knowledge of mailing lists. For users without the understanding of how Trac works. They are the people that interact with the majority every day. They are the voice of the majority.

Don’t let their voices go unheard.