Tom Lany

<p>In WordPress 3.0 and later, <a href="https://core.trac.wordpress.org/changeset/14996" rel="nofollow ugc">a default filter</a> changes all instances of “WordPress” (note the small “p”) in posts, titles, and comments to “WordPress”. <a href="https://core.trac.wordpress.org/ticket/13583" rel="nofollow ugc">For various reasons</a>, such as preserving spelling in existing posts and comments, a blog owner may want to turn this filter off. That is what this plugin does.</p>
<p>Simply upload the plugin files to your WordPress plugins folder, activate it on your blog’s Plugin administration page, and you are set!</p>
<h3>Technical Details</h3>
<p>This plugin seeks to disable the capital_P_dangit function, which is the WordPress function that disallows “WordPress” to be used on blogs.</p>
<p>The filter is defined in <a href="https://core.trac.wordpress.org/browser/trunk/src/wp-includes/default-filters.php" rel="nofollow ugc">wp-includes/default-filters.php</a> and is applied in <a href="https://core.trac.wordpress.org/browser/trunk/src/wp-includes/formatting.php" rel="nofollow ugc">wp-includes/formatting.php</a> of the core WordPress code.</p>
<p>The remove_filter function is used in this plugin to undo the add_filter function applied in wp-includes/formatting.php. In versions 1.0 and 1.1 of this plugin, the function was removed for certain priority levels. As of version 1.2, this plugin removes the filter for all possible priority levels. Thanks to <a href="http://subscribe2.wordpress.com/" rel="nofollow ugc">Matt Robinson</a> for suggesting this method and providing code that is used in the plugin.</p>
<p>For more information regarding how this function is applied in WordPress, the following are the relevant changesets to the core WordPress code regarding this function:</p>
<ul>
<li><a href="https://core.trac.wordpress.org/changeset/14996/" rel="nofollow ugc">Changes made for WordPress 3.0</a></li>
<li><a href="https://core.trac.wordpress.org/changeset/15377/" rel="nofollow ugc">Changes made for WordPress 3.0.1</a></li>
<li><a href="https://core.trac.wordpress.org/changeset/15877/" rel="nofollow ugc">Changes made for WordPress 3.1</a></li>
<li><a href="https://core.trac.wordpress.org/changeset/21242/" rel="nofollow ugc">Changes made for WordPress 3.5</a></li>
<li><a href="https://core.trac.wordpress.org/changeset/25093/" rel="nofollow ugc">Changes made for WordPress 3.7</a></li>
<li><a href="https://core.trac.wordpress.org/changeset/26122/" rel="nofollow ugc">Changes made for WordPress 3.8</a></li>
</ul>


Remove WordPress to WordPress filter

Brilliant

This turns off the default filter that changes all instances of "Wordpress" to "WordPress".

bobbingwide

vsgloik

<ul>
<li>The primary purpose of debug trace is to help in the development of PHP code: plugins or themes.</li>
<li>The primary purpose of action trace is to help you understand the sequence of events in the server.</li>
<li>The primary purpose of ad hoc tracing is to let you see what’s happening without changing any code.</li>
<li>The primary purpose of ‘string watch’ is to track the source of some output.</li>
<li>This plugin provides the admin interface to trace functions and methods and action and filter tracing.</li>
</ul>
<p>oik bwtrace does not alter the output of your web pages though there are options<br />
which cause some output to be written to the browser during ‘shutdown’ processing.</p>
<p>You can also use the oik trace facilities to assist in problem determination in a live site.<br />
Output is written to files on the server in a user defined trace files directory.<br />
When tracing a live or staging site you should ensure that the trace files directory is not publicly accessible.</p>
<p>Features:</p>
<ul>
<li>Traces to a defined Trace files directory</li>
<li>Traces ALL server functionality, including AJAX, REST and other background requests</li>
<li>Writes summary trace record for each transaction into Daily Trace summary files</li>
<li>Traces browser transactions separately, if required</li>
<li>Traces AJAX transactions separately, if required </li>
<li>Traces REST requests separately, if required</li>
<li>Traces CLI requests separately, if required</li>
<li>Ability to choose the IP address to trace, defaults to ALL requests</li>
<li>Supports ad hoc tracing of user defined hooks</li>
<li>Action trace counts help you understand the sequence of actions and filters</li>
<li>Provides contextual information</li>
<li>Minimum performance overhead when tracing is not enabled</li>
<li>Tracing can be enabled programmatically</li>
<li>Traces and backtraces PHP Error, Warning and Notice messages</li>
<li>Backtraces deprecated logic messages</li>
<li>Does not require WP_DEBUG to be defined</li>
<li>Does not require SAVEQUERIES to be defined</li>
<li>Dynamically activates trace functions</li>
<li>Implemented as lazy just-in-time code</li>
<li>Can be used during regression testing</li>
<li>Can be activated in wp-config.php and db.php to trace code before WordPress is fully loaded</li>
<li>Plugin does not need to be activated if started programmatically or from wp-config.php</li>
<li>Operates as a standalone plugin</li>
<li>Integrated with oik-lib shared library management</li>
<li>Easy to code APIs: bw_trace2(), bw_backtrace().</li>
<li>API supports multiple trace levels</li>
</ul>
<p>Ad hoc tracing allows you to:</p>
<ul>
<li>trace parameters</li>
<li>trace results</li>
<li>trace registered functions</li>
<li>trace the global post</li>
<li>set the priority for the trace hook</li>
<li>debug backtrace hook invocation</li>
<li>perform ‘string watch’ to watch for a particular string</li>
</ul>
<p>The trace record output can include:</p>
<ul>
<li>Fully qualified source file name</li>
<li>Trace record count and trace error count</li>
<li>Time stamp</li>
<li>Current filter information</li>
<li>Hook count</li>
<li>Number of database queries that have been performed.</li>
<li>Current post ID</li>
<li>Current and peak memory usage (in bytes)</li>
<li>Files loaded count</li>
<li>Contextual information</li>
</ul>
<p>The output for action tracing can include trace records showing:</p>
<ul>
<li>Count of action hooks and filters</li>
<li>Invocation of the ‘wp’ actions</li>
<li>Contents of the global wp_rewrite for the ‘wp’ action</li>
<li>Summary reports at ‘shutdown’</li>
<li>Information about deprecated logic</li>
<li>Information related to Errors, Warnings and Notices</li>
</ul>
<p>New in v3.4.0</p>
<ul>
<li>Experimental Performance trace option</li>
<li>Experimental front end links to trace file and daily trace summary</li>
</ul>
<h3>Is there a tutorial?</h3>
<p>See this page and short video<br />
<a href="https://www.oik-plugins.com/wordpress-plugins-from-oik-plugins/free-oik-plugins/oik-trace-plugin/an-introduction-to-problem-determination-with-oik-bwtrace-debug-trace-for-wordpress" rel="nofollow ugc">Introduction to oik-bwtrace</a></p>
<h4>Can I get support?</h4>
<p>Use the contact form on the oik-plugins website.</p>
<h4>How can I contribute?</h4>
<p>[github bobbingwide oik-bwtrace]</p>
<h3>Further reading</h3>
<p>If you want to read more about the oik plugins then please visit the<br />
<a href="https://www.oik-plugins.com/oik" rel="nofollow ugc">oik plugin</a><br />
<strong>“the oik plugin – for often included key-information”</strong></p>


oik bwtrace

With the addition of Ad hoc tracing and the fact that oik-bwtrace doesn't affect what's displayed on the front end(*) oik-bwtrace is my GO TO plugin for problem determination... finding out what's really going on.
Most of the other debugging plugins only work on the front end and alter what's sent to the browser.
(*) With some minor exceptions.



Comes into its own when tracing back end activity

Debug trace for WordPress, including ad hoc action hook and filter tracing.

Remove WordPress to WordPress filter vs oik bwtrace