Recently I’ve found that the more context you can get to an issue the easier it is to understand and debug and I also noticed that while we recorded a simple backtrace for queries in core when SAVEQUERIES was defined we didn’t do a good job of presenting the data. Some function calls need more context that just the function name to be most useful – such as when running an action/filter it is useful to know the name and when requiring or including a file is useful to know the file name and some path context. This lead to the idea of refactoring the backtrace capture functionality out of WPDB and into a function that was improved to give proper calling syntax for functions in classes when called statically and was more obviously re-usable by plugins like the Debug Bar.

So today I have introduced wp_debug_backtrace_summary( $ignore_class = null, $skip_frames = 0, $pretty = true ) for #19589. If you provide no arguments you will get back string containing the full trace of the code run up to the place where you call wp_debug_backtrace_summary() – you won’t see the call to it in the trace as it always hides itself.

The best way to see the difference and improvements is to look at how this improves the information in the development version of the Debug Bar (new release coming soon) so after the break I have included some before and after screenshots.

Debug Bar query list before the change showing the previous limited infomation

Development version of the Debug Bar showing the enhanced details

An example of how the Debug Bar currently displays warnings, notices and deprecated function calls.

The development version of the Debug Bar showing how it can use this new function to display much more useful information

One of the things I suspect I will be doing a lot with this new function is dropping calls to error_log( wp_debug_backtrace_summary() ); into code that I am trying to debug and work out how often and from where it is being called.  In the past I’ve done this by using print_r( debug_backtrace() ); which prints out a lot of information (some of which is pretty useful) and more recently I’ve been using print_r( debug_backtrace( false ) ); so as to only fetch and print the stack traces.

Using this new function does mean I lose by using  the access to line numbers and file names I had from the raw PHP functions but I find that with the file names in the require/include calls and the function name being called I can get to the code just as fast as before.

I hope you all put this new function to good use!

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 11,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 4 sold-out performances for that many people to see it.

Click here to see the complete report.

During the development and RC phase for WordPress 3.1 some of the core development team have worked on building a plugin which adds these debugging features to any site running WordPress 3.1 or later.  The plugin started out with a very basic feature set just including MySQL query debugging information and statistics from the installed object cache based on the code that is used on WordPress.com.  Overtime we have added reporting of PHP notices and warnings, Logging of calls to the things that are deprecated (code derived from the Log Deprecated Notices plugin by Core Developer Andrew Nacin) and information about the WordPress Query being run as well as how the current request has been parsed by the WordPress rewrite engine.

The plugin requires WordPress 3.1 as it hooks into the new Admin Bar and I’m sure will be of great use to all WordPress core, plugin, and theme developers.

By default the MySQL queries and PHP Notices / Warnings tabs are not displayed. If you enable MySQL query recording with the SAVEQUERIES define in your wp-config.php then the queries tab will show. If you enable WP_DEBUG in your wp-config.php then the PHP Notices / Warnings tab will show.

Here are some screenshots of the plugins different tabs:

A list of all the MySQL queries made for the current page load and details about what function calls generated them

This shows statistics information from the object cache - content depends on which object cache you are using

Details on any php notices or warnings on the current page

Details on the calls to deprecated functions etc.

Details on the current WP Query object

Details on the parsing of the current request by the WordPress rewrite engine

You can find the plugin in WordPress.org Extend here: http://wordpress.org/extend/plugins/debug-bar/

Is there something else you think this plugin could provide debugging information on?

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

About 3 million people visit the Taj Mahal every year. This blog was viewed about 52,000 times in 2010. If it were the Taj Mahal, it would take about 6 days for that many people to see it.

In 2010, there were 4 new posts, growing the total archive of this blog to 56 posts.

The busiest day of the year was May 3rd with 2,131 views. The most popular post that day was Themes and WordPress 3.0 some important changes.

Where did they come from?

The top referring sites in 2010 were wordpress.org, WordPress Dashboard, wpdevel.wordpress.com, planet.wordpress.org, and Google Reader.

Some visitors came searching, mostly for wordpress 3 themes, wordpress 3.0 themes, westi, themes wordpress 3.0, and wordpress 3.0 loop.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Themes and WordPress 3.0 some important changes May 2010
18 comments

Making it easy to be a WordPress Tester June 2009
8 comments and 1 Like on WordPress.com,

Making your broken Plugin work again with WordPress 2.8.1 July 2009
16 comments

Introducing menu_page_url() June 2010
15 comments

Giving your WordPress a check up December 2009
22 comments

Basically we are just trying to emphasise that in an open source project like WordPress, where direction is driven by the community with responsibility gained through the mechanisms of meritocracy, the best way to improve things is to write a patch.  This doesn’t have to be a patch for the PHP code it could also be a patch for the CSS or an update to the documentation on the codex or helping out people on the support forums.

On the way back from WordCamp UK last weekend I had the idea for a new site where we could collect together information around how to get involved and so I have set up a new site called “Patches Welcome” and have started writing over there too.  The aim for the site is to collect together tutorials, a question and answer list, contributor interviews and other things as the site develops.

I posted the first of the contributor interviews yesterday and have already got some questions coming in and ideas for tutorials for the coming weeks.

Please let me know if you have any ideas or questions using the contact form on the site.

It is now really easy to get the url for a plugin page that you have registered to make it easy to link between different plugin pages. You use the new function like this:

add_options_page('Best Evar Menu', 'Best Evar Menu', 'manage_options', 'best_evar_menu', 'best_evar_options_page');

menu_page_url( 'best_evar_menu' );

The function will by default echo the url out but if you want you can get it returned for processing by setting the second argument to false.

1) get_template_part – [13146], #12371

The first change which should make it easier for extensible flexible theme development is the introduction of get_template_part() which has been introduced as a generic way of modularising themes a step beyond the basic footer/body/header files.  This new function makes it very easy for a theme to reuse blocks of code implementing theme areas such as the WordPress loop in a way which makes it easy for a child theme to override the implementation in a context sensitive way.

This function is really easy to use – You create a file within your theme containing the code you want to re-use and then you pull it in as follows:

get_template_part( 'loop', 'author' ); // Pull in the loop for the author archives

This will look for the files loop-author.php and loop.php searching first in the current themes folder before looking in the parent themes folder (if one if defined).  The new TwentyTen theme in WordPress 3.0 uses this for every call to it’s loop.php to make it easy to override in a single instance from a child theme.

2) Deprecating overly minimal themes [14365], #12425

The next change is to deprecate the support for overly minimal themes.  Prior to WordPress 3.0 any theme which was using the relevant template tag but missing any of the following template files – header.php, footer.php, sidebar.php, comments.php, comments-popup.php – would effectively behave as if it has a parent theme defined as ‘default’ using the relevant files from the old default theme.

Now that we are moving to a new default theme we didn’t want to have to support this very old behaviour indefinitely or make it such that the files from the TwentyTen theme were used as they have a different visual layout and would like change peoples existing sites.

Going forward a WordPress theme using the relevant template tags is expected to contain all these files itself, or have them provided by a parent theme, and the theme compatibility files included in WordPress 3.0 will be removed in a future version.

If you are using a theme which is affected by this change then you just need to make sure that you have the default theme installed – it will not be in new installs but will be preserved on upgrades. Then add the following to the comment at the top of the style.css of your theme to make it such that the default theme is used as its parent theme:

Template: default

More information on the process of indicating a parent theme in a child themes style.css is available in the codex.