Matt Mullenweg is one of the founders of WordPress (thanks!) and back in 2010 he committed a new piece of code to correct automatically every single “Wordpress”, without a capital P, to “WordPress“, with a capital P. This automatic correction is commonly known as the Capital P Dangit filter.
If you prefer full editorial control over capitalization, you can disable this filter. The performance impact of leaving it enabled is negligible, as capital_P_dangit() is a simple string replacement applied in a few contexts. For most sites this is about style and editorial consistency, not speed. If you actually want to improve the speed of your WordPress, we can help you anyway!

To do this, this is the code snippet you’ll need:
/* Remove Capital P Dangit everywhere */
remove_filter( 'the_title', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'comment_text', 'capital_P_dangit', 31 );
remove_filter( 'document_title', 'capital_P_dangit', 11 );
remove_filter( 'widget_text_content', 'capital_P_dangit', 11 );
remove_filter( 'wp_title', 'capital_P_dangit', 11 ); // for older themes still using wp_title()
When you should or shouldn’t disable this
- Should: Your style guide allows lowercase “Wordpress” in quotes or code examples, or you want zero automated changes in titles, content, comments, and widgets.
- Shouldn’t: Your team follows the official capitalization of the WordPress project and wants that consistency enforced automatically.
Safety notes (read before you edit anything)
For persistent, update‑safe changes, avoid editing a parent theme’s functions.php. Use one of the following instead:
- Child theme: Add the code to the child theme’s
functions.phpso updates to the parent don’t overwrite it. - Site‑specific plugin: Create a tiny plugin that contains only this snippet. Activate it like any normal plugin. This keeps the change independent of your theme.
- MU plugin: Place a single PHP file in
/wp-content/mu-plugins/. It loads automatically on every request and across theme changes.
Test on staging first, then push to production. Keep file access (SFTP or host file manager) and admin access ready in case you need to revert.
Rollback
- If you added code to a child theme: remove the lines and save.
- If you created a site‑specific plugin: deactivate it or temporarily rename the plugin’s folder.
- If you used an MU plugin: rename or delete the MU plugin file in
mu-plugins(no deactivation screen for MU plugins).
How to implement
Option A: Child theme
- Open (or create) your child theme’s
functions.phpfile via SFTP, host file manager, or the WordPress admin’s Theme File Editor (Appearance → Theme File Editor, if enabled). - Add the code snippet to the end of the file:
- Save the file. If you’re editing locally, upload it back to
/wp-content/themes/your-child-theme/functions.php, overwriting the existing one. - Clear any caches and verify.
A couple of notes specific to this option:
- Don’t include a
<?phpopening tag if you’re pasting into the middle of an existingfunctions.php. It should already have one at the very top of the file. Only add it if the file is empty. - This only works if you’re actually running a child theme. If you add this to a parent theme’s
functions.php, it’ll be wiped out on the next theme update, which is exactly what the safety note at the top is warning against.
Option B: Site‑specific plugin
- Create a new file named
my-plugin.phpon your computer (replacemy-pluginwith whatever you want). - Paste this code and save (remember to replace the relevant texts:
<?php
/**
* Plugin Name: My plugin
* Description: Description of the plugin
*/
the_code_snippet_goes_here
- Upload the file to
/wp-content/plugins/, then activate it in Plugins. - Clear any caches and verify.
Option C: Must‑use (MU) plugin
- If it doesn’t already exist, create the folder
/wp-content/mu-plugins/. - Create a file named
my-plugin.phpwith the same code as option B. - Upload the single file to
/wp-content/mu-plugins/. MU plugins load automatically; there’s no activate/deactivate screen.
Verification
- Create a draft post titled Wordpress test. The title should remain exactly as typed (no autocorrect to WordPress).
- Add the phrase Wordpress to the content and to a comment on a test post; confirm it’s not auto‑corrected.
- Look at the browser tab/title for a single post and the home page to confirm the
<title>is unaffected. - Place a Text widget (or Paragraph block in a widget area) with Wordpress and confirm there is no change.





