Headed to WordCamp New York City

Posted on 14 Oct 2010 by Matt

It’s that time of the year again and my favorite WordCamp is about to begin. Last year I made the trip to WordCamp NYC and spoke in two sessions. I had an immense amount of fun last year, and even though I have moved from the East Coast to Texas I couldn’t pass up the opportunity to attend again.

The company that I now work for, Rackspace, who is a big supporter of WordPress will be sponsoring the event as well as sending myself and Rob Taylor.

As with last year I will be speaking, this time about Performance and Optimization. The Performance and Optimization session will be a panel with myself and Scott Taylor. I will be focusing on “Building a High Performance WordPress Environment” and Scott will be focusing on “Front End Optimization Tools”. If we are able to get a third person on board they will be covering “CDNs and Offloading”. We will be keeping the presentations short to allow time for a question and answer session as well as some discussions between the panel members about certain aspects of performance and optimization in WordPress.

WordCamp NYC will also be holding a Genius Bar as does every other WordCamp, but the one thing most other WordCamps don’t have is me. One other special event happening at WordCamp NYC is the Hacker Room, where myself, Andrew Nacin, Daryl Koopersmith and other WordPress core contributors will be spending time over the 2 day event to write patches for WordPress 3.1 which is just about to hit feature freeze. If you are interested in helping out and getting started with WordPress core development please stop by.

Posted in Locations, New York, New York City, Talks, US, WordCamp, WordPress | 1 Comment

WordPress One Liner to Customize Author Permalink Redeux

Posted on 06 Oct 2010 by Matt

Nearly 2 years ago I wrote a one liner for someone in the WordPress IRC channel to change the author permalink structure. At the time I had not taken the time to really understand WP_Rewrite and as such didn’t understand the implications of flushing the rewrite rules on each page load.

It is sufficient to say that since then, I have taken the time to understand it better and I am fully aware of the negative implications of performing flushes every time someone hits your site. For one thing the default behavior of flush_rules() is to also update the .htaccess file as well as updating the serialized array in your wp_options table that contain the internal WordPress rewrites. Assuming you are using a nasty permalink structure that starts with something like %category% or %postname% that serialized array can grow exponentially with the number of pages you have 1.

To make a long story sort, I have known that I should have changed the code for almost as long as the post has been published, but I was too lazy to do anything about it. It took a few carefully placed pokes and prods to get me moving, and as such I have updated the post to reflect the removal of using flush_rules().

Notes:

  1. Otto explained this a bit more in depth at http://ottopress.com/2010/category-in-permalinks-considered-harmful/ ↩
Posted in Code, One Liner, PHP, Snippet, WordPress | Leave a comment

WordPress Metric Comparison of 2.9.2 and 3.0

Posted on 04 Jul 2010 by Matt

Some times I like to look at metrics. Because I am bored? Probably. Without metrics how can really compare things. In any case I wanted to see the difference in the number of queries, generation time and peak memory usage between WordPress 2.9.2 and WordPress 3.0.

One of the things that I have heard people say since the release of WordPress 3.0 is that it is noticably faster. “Is it really?”, I asked myself. No, not out loud…or was it? Generally as much as we would like to make things faster from one release to the next, it doesn’t really happen that way. There are new features added, rewrites of code, a new default theme and in the end metrics change.

So what really changed in the way of these 3 aspects of number of queries, generation time and peak memory usage?

2.9.2:

  • 18 queries
  • 0.173 seconds
  • 15.901 MB peak memory used

3.0:

Kubrick

  • 16 queries
  • 0.209 seconds
  • 18.301 MB peak memory used

Twenty Ten

  • 15 queries
  • 0.212 seconds
  • 18.32 MB peak memory used

I have provided results as well for Twenty Ten, but so that we can perform a more apples to apples comparison we will use Kubrick. We have reduced the number of queries by 2 from 2.9.2 to 3.0, but it took 0.036 seconds longer to generate the page. In addition we now consume 2.4 MB more memory to generate the output.

I used the following code, placed at the very end of footer.php of the default theme for 2.9.2 and the very bottom of footer.php in twentyten. In 2.9.2 I removed the timer_stop line that already existed in the footer.php of the default theme.

<!--
<?php echo get_num_queries(); ?> queries
<?php timer_stop(1); ?> seconds
<?php echo round(memory_get_peak_usage() / 1024 / 1024, 3); ?> MB Peak Memory Used
-->

The testing set up:

  • Ubuntu 10.04
  • Apache 2.2.14
  • PHP 5.3.2 (Only enabled modules were mysql, gd and curl)
  • MySQL 5.1.41 (With all caching disabled)
  • Fresh installs of WordPress without any enabled plugins or modifications
  • Tests performed using curl against the front page
  • Averages over 25 tests per install

Anyway, not really the most comprehensive metrics gathering test, but just something to look at. But in the end, is WordPress 3.0 any faster? With an absolute default install, no. Does it matter that 3.0 is ever so slightly slower? No. Should I be running WordPress 3.0 now? Yes!

Hopefully you find this post useful and that I didn’t waste 15 minutes of my day that I will never get back to talk about something you could care less about.

Posted in Code, CoolStuff, Fun, PHP, WordPress | 8 Comments

Using MySQL Sockets in the WordPress wp-config.php

Posted on 30 Jun 2010 by Matt

Recently I have been getting a lot of questions about how to use a MySQL socket in place of the DB_HOST constant for WordPress in the WordPress IRC channel.

Fortunately this is pretty easy, unfortunately if you are using the web based installer you cannot specify a socket in the “Database Host” field. However, you can do things the manual way and copy wp-config-sample.php to wp-config.php and go that route.

The first thing you need to do is determine the path to the MySQL socket. By inspecting my.cnf you would need to look for something that looks like:

socket      = /var/run/mysqld/mysqld.sock

If you don’t have access to look at my.cnf you can try to run the following MySQL query:

SHOW VARIABLES LIKE 'socket';

Now crack open your wp-config.php file and set DB_HOST to ‘:/path/to/mysql.sock’. Take careful note of the ‘:’ (colon) preceding the path. In my example the define for the DB_HOST looks like:

define('DB_HOST', ':/var/run/mysqld/mysqld.sock');
Posted in CoolStuff, HowTo, WordPress | 3 Comments

Detect wp_head and wp_footer from a Plugin

Posted on 25 Apr 2010 by Matt

Normally I start these posts with “Every so often someone asks a question in the WordPress IRC channel that sparks my interest”, however today, to my great surprise someone actually caught my attention on the wp-hackers mailing list.

For those of you who didn’t click through, the question was:

Couldn’t find this on forums or anywhere else.
What can I test to check if wp_footer was placed on the theme?

Before any replies came in I was already interested and when Peter Westwood replied with “The other way to do it is to do a http request based test which a special query arg on which you output a string on wp_footer.”, I was on the hook.

I spent a few minutes writing up a test plugin, to perform only this functionality and responded back to the list. It was pretty well accepted and I got a few comments from Ozh and Andrew Nacin on Twitter. One of the comments was actually an idea, to extend the checks to make sure that the calls to <?php wp_head(); ?> and <?php wp_footer(); ?> were in the proper places in the code.

Before I get to the code, I want to spend a little time talking about the significance of wp_head() and wp_footer(). These 2 functions are the key to functionality of a lot of plugins and are the real work horses of themes. The wp_head and wp_footer functions allow WordPress core and plugins to hook into your theme either directly before the </head> or </body> html tags in your theme and perform actions. The majority of the time these actions are used to output style sheets or JavaScript, for use by plugins. WordPress core uses it to output a lot of good functionality such as relational links to your RSS and ATOM feeds into the head of the document. Joseph Scott wrote about this nearly a year ago. His post is fairly short but does a good job at explaining why it is important to include these functions.

Back to the original discussion, which was how do we detect whether or not wp_head and wp_footer are called in the active theme, and if called are they called, was it from the proper locations?

In my proof of concept plugin, we hook into admin_init, which will actually use wp_remote_get() to retrieve the frontend of our WordPress site. It calls the url with 2 query vars, that if present will cause the plugin to hook into wp_head and wp_footer and output some content that we will later look for. If the response was successful, as in returning a 200 response code, we will look at the content to see if <!--wp_head--> and <!--wp_footer--> are present. If they are not we will see an admin notice telling us which problems were found. If those strings were found but they were not found directly before </head> or </body> the notice will alert you of such.

Without further adieu:

Just in case you cannot see the code above, use this link: http://paste.sivel.net/24.

Posted in CoolStuff, Fun, HowTo, PHP, Plugins, Questions, Uncategorized, WordPress | 7 Comments