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!
Actually, Ozh wrote that plugin. I just looked up the download stats.
But its download numbers are irrelevant to Matt. He has stated that a plugin to remove the filter would need to generated 50,000 downloads to be considered seriously as justification for removing the capital_P_dangit filter from core.
Obviously, the pedantic whims of Matt outweigh any reasonable debate.
Thanks for the correction. I’ve updated that part.
You are right that it seems that sometimes rational discussion or debate is impossible at times. But then again, we see how sports teams are able to get people to fill-the-ballot-box to get a team member on the all-star team. I guess its time to go start “downloading” 50,000 times.
[...] The dangit filter by Benjamin Bradley [...]
[...] (8 July 10): Hier noch einige Links (englischsprachig)Lowercase p, dangit! von Justin TadlockThe dangit filter von Benjamin BradleyAutomatically Correcting The WordPress Mistake von Jeff ChandlerChangeset 14996 [...]
where exactly does one put that code in the functions.php file how about an example?
You can place the code at the bottom of the functions.php file that exists in your active theme directory folder. If there is no functions.php file in your active theme directory folder, you can create a new .php file with the name functions.php. Then put the code in-between the closing tag.
I really appreciate having this code. I noticed when copying it that some of the single quotes pasted in as curly quotes. Thanks goodness for color-coded editing software!
Mucho gracious, professor.