Category Archives: wordpress

SSL all the things

Security is important and one of the things I would like to see is if we can enforce a requirement for all requests that core makes back to WordPress.org for updates and information to be https. This is the a great step to a greater level of update verification to help detect man-in-the-middle attacks.

Making this switch is going to be a fun journey and we are bound to find that there are some setups that can’t/don’t/won’t support https with the WP_HTTP API.

So before we try switching to using https in trunk I’ve update the Beta Tester plugin so that it forces all requests to api.wordpress.org to happen over https. I’ve also updated the api so that if you make a https request it will return https references in the results.

Please go for and test this on your test installs and let us know of any issues you find here in the comments or on the trac ticket.

Tracing things back to where they came from

One of the things I find myself doing a lot when developing WordPress is debugging things and so I spend a lot of time thinking of ways I can make this easier for me and easier for everyone else. Overtime this had led to a number of significant improvements to the debug ability of WordPress core including things like WP_DEBUG and the Deprecated Notices as well as the development of great tools like the Debug Bar plugin.

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.

Continue reading

Introducing Debug Bar

One of the features being introduced in the upcoming WordPress 3.1 release is the new Admin Bar.  This is designed to make it easier to get access to the more common administration area tools from the front end of your site but also introduces the possibility to easily integrate extra debugging features into your site for use in testing environments or production environments to help track down things like slow queries, PHP notices and warnings, and usage of deprecated functions.

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.
Read on for more information and screenshots

2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

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

Crunchy numbers

Featured image

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.

1

Themes and WordPress 3.0 some important changes May 2010
18 comments

2

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

3

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

4

Introducing menu_page_url() June 2010
15 comments

5

Giving your WordPress a check up December 2009
22 comments

“Patches Welcome”

Occasionally you may have seen or heard myself or one of the other members of the core WordPress team saying “Patches Welcome” and wondered what this was all about.

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.