Recently there has been a bit of a back and forth between developers who use WordPress on a daily basis for client or development work and the core development team of WordPress.  At the center of the issue is a piece of code that got inserted into WordPress core before WordPress 3.0 was released.  What this little piece of code does is that every time the word “wordpress” appears (the lowercase typing of the word WordPress is intentional right there) the code automatically modifies it to “WordPress”.

Yes, the word is WordPress…

My friend @lelandf has put together a great site called WPCamelCase.com that is useful in instructing people in the correct spelling/formatting of the word WordPress.  He makes a “strong-case” for the correct-case:

• NOT: WordPress
• NOT: wordPress
• NOT: wordpress
• NOT: Word Press
• NOT: word press
• NOT: automaticPress
• NOT: MattPress
• NOT: WoRdPrEsS
• YES: WordPress

So, what’s the big issue?

Some people think this is no big deal and that people who don’t like this new “forced-filter” are just trying to stir up trouble.  But there are several real issues and problems this “forced-filter” piece of code are causing.  Examples like:

• This forced-filter code can break links on some sites.  This is especially true is you install WordPress in a subdirectory called /Wordpress.  This would cause major problems when trying to display images or linking to specific files in that directory.
• The response from some of the core development team is very dismissive of the community.  (And an open-source project, which WordPress IS one, relies heavily on the community for development.)
• The code, which by the way is actually called capital_P_dangit(), was put into the core of WordPress without even a Trac ticket and therefore there was zero discussion that the community was engaged in before it was released.
• Plus, there’s the whole issue of WordPress now having editorial control over my content.  Which is a bit backwards… I should be the one with editorial control over my own content.
• Justin Tadlock has a great post about the lower vs. upper case “p” issue.

If you’ve taken the time to read through @justintadlock’s well thought out case (great post), you should begin to understand why this is a big issue.  If you are a theme developer, work with client projects, or some other project dealing with WordPress, I would encourage you to use a small bit of code in your theme’s functions.php file.  These three lines of code will remove the capital_P_dangit() code from the filters and protect your content and therefore nullify the issue.

remove_filter(‘the_content’,'capital_P_dangit’);
remove_filter(‘the_title’,'capital_P_dangit’);
remove_filter(‘comment_text’,'capital_P_dangit’);

Side Note: Something interesting to note is that almost three years ago, Chip Bennet Ozh had written a plugin that essentially does the same thing as the current forced-filter capital_P_dangit().  Currently it barely has over 300 downloads.  This should say something about users desire to have WordPress auto-correct their spelling and usage of the word “WordPress”.   This comparison is important because Matt Mullenweg has stated that if you don’t like a filter or feature, vote with your feet or with a plugin.  Voting with a plugin is a good idea and based on the 3 year history of only 300 sites using the auto-correcting plugin versus the millions of sites who don’t use it…. that should be enough to prove we don’t need this type of forced_filter added to core.

It’s time to remove capital_P_dangit() from core DANGIT!