A complicated theme will use extra queries and this is acceptable if you need extra loops or recent comments or other special items. However, the key issue in this case is a theme framework with its significant overhead coupled with a sidebar employing 10 widget sections and over 30 different widgets.

I don’t want to sound like a broken record, but themes that allow the user to change settings within the WordPress interface generate overhead. Widgets generate additional overhead. For a high traffic site or even a significant burst of traffic, this can bring a site to its knees.

How can you fix this problem? Well, optimally, you recode the entire template so it doesn’t use any widgets or settings stored in the database. Is this painful, expensive and unreasonable? Yes, yes and no. What if you are not currently in a place where recoding the template is reasonable? Well, then you try to optimize what you can and get the query count as low as possible.

Most themes store settings in the WordPress options table and access them using the get_option() function. The theme set I’m trying to salvage uses get_option() 162 times. Finding a way to reduce the impact of these calls is probably a good place to start. Simply getting all the theme options in a single query and using cached values instead of reading them when needed should help reduce the number of total queries on each page.

To do this, first we need to figure out how to identify the theme specific options. Usually there will be a prefix on each option name, so I’ve created a new function in functions.php that reads all the options with that prefix and then I call it:

function theme_cache_options($prefix) {
  global $wpdb;
  global $theme_cached_options;

  $sql = "SELECT option_name, option_value FROM ".$wpdb->prefix."options ".
        "WHERE option_name LIKE '%s' AND blog_id = %d";
  $prepared_sql = $wpdb->prepare($sql, $prefix.'%', get_current_blog_id() );
  $theme_cached_options = $wpdb->get_results($prepared_sql, OBJECT_K);
}
theme_cache_options(‘cow_’);

Second, we need a function that lets us read the cached option value:

function get_cached_option($key) {
  global $theme_cached_options;
  $result = isset($theme_cached_options[$key]) ?
        $result = $theme_cached_options[$key]->option_value : '';
  return $result;
}

Finally, we need to go through the theme itself, and change every get_option() call that references a theme setting to get_cached_option(). Be sure not to change any option requests that do not start with the prefix specified in the theme_cache_option() call.

Does this help? Well, it helps a little. With the site I’m working on, I’m seeing roughly a 10% reduction in the number of queries. Worth it? I think so.

Final note for theme developers: If you are going to store theme options in the options table, there is a fourth parameter for the add_option() function that you should really be aware of. If you set $autoload to ‘yes’, then WordPress will automatically load and cache that option when it fires up. This means that get_option() calls for any option that was created with $autoload set to ‘yes’ will not generate any additional queries.

I’ve worked with WordPress since it first came out, and I’ve supported a number of very high traffic sites. The items below are what I’ve learned about making WordPress work better and faster:

Actions that are Free (or Mostly Free)

Actions that cost money

I hope at least some of that is new information and helps you make sure your site delivers your content as fast as possible. I know some people will disagree with some of this and I fully expect hate mail from some who either develop or employ Frameworks, which is fine. The point of this post was not to please everyone, but simply to take a critical look at anything that adds overhead to WordPress and ways to reduce it.

Similar to the Pharma-Hack, there is a new stealth hack which affects compromised WordPress sites and most people have no idea their site is infected. The reason for the ignorance is that the hack doesn’t affect any content on the infected site – except for pages delivered to googlebot. For those pages, it injects “Free live streaming porn – ” in front of page titles which gives nasty search results for innocuous content.

Take a look at these search results: google search for: “Free live streaming porn”. (Link is SFW).

About 11 million hits and if you read the summary content, most are blogs or pages from a WordPress installs that have search results that are injected with a bogus title and keywords. (Either the hack does not target Bing and Yahoo, or hacked pages end up futher down in the result set for those search engines, at least that is what I saw on those sites with the same search.)

So how do you know if your blog is one of these hacked sites? Do the same google search with the site tag:

“Free live streaming porn” site:blogrescue.com

Mine comes up clean, but it is probably a good idea to check yours. If you are infected, then you need to deal with the issue right away, and then comes the agonizing wait for googlebot to recrawl these pages and replace the damaged pages with the real version.

wp_deregister_script('admin-bar');
wp_deregister_style('admin-bar');
remove_action('wp_footer','wp_admin_bar_render',1000);

The above code is pretty common in 3.1 themes to permanently remove the bar from the theme. However, in 3.3, the bar still appears in wp-admin but it isn’t pretty. If you have a blank space for the bar but it isn’t visible, try scrolling to the bottom and see if you have unstyled bar items on the bottom left of the page. Then check your functions.php for the code above and comment it out.

More Info here.

I’d glanced at SASS before, but today someone brought it back to my attention and my first thought was “How can I use that in WordPress?” A few hours of coding and testing later, I’ve got a pretty nifty plugin solution for anyone who wants/needs SASS features.

It is probably less than perfect since it uses a fairly dated php port of HAML/SASS. Any limitations of that code will reflect in the plugin since it just serves as a wrapper. However, it does not require Compass installed on the server and is really easy to install and start using.

Here is the plugin:

Here is how to make it work:

1. Install the plugin.
2. Copy style.css to style.scss in your theme.
3. Add the following code to your theme’s functions.php.

// Enables SASS to CSS automatic generation
function generate_css() {
  if(function_exists('wpsass_define_stylesheet'))
    wpsass_define_stylesheet("style.scss", "style.css");
}
add_action( 'after_setup_theme', 'generate_css' );

4. Make style.css writable (0775).
5. When editing the stylesheet, make all updates in style.scss only.
6. The plugin detects when style.scss has been updated, and rebuilds style.css from it.

If you try it, let me know how it goes and what you think of SASS.

TimThumb is a pretty cool script that provides on-the-fly cropping and resizing of images.  It is cool enough that it has been included in a large number of WordPress plugins and Themes (both free and paid).  Unfortunately, there is a pretty significant exploit which allows hackers to upload or modify php scripts on your system.  That, in turn, gives them access to do just about anything they want.

Millions of wordpress installs are at risk from this issue…which raises the big question: how do I know if I have a problem?  Fortunately, Peter over at Code Garage made it easy - there is now a plugin which scans your install and tells you if you are vulnerable or not.

I highly recommend that all WordPress blogs take this simple action right away – installing and running the plugin is considerably easier than recovering from a hacked install.

First, find the following code (should be somewhere around line 64):

var $featured_images = array();

Just below that line, add the following:

var $import_filename = '../export.wxr';

Please note that export.wxr should be changed to the name of your import file. Also note that the when the file is uploaded, it needs to be in the wordpress root (where wp_config.php and the wp_admin folder are located).

Second, there is a switch statement in the function named dispatch. Find it and make the following changes to it:

switch ( $step ) {
  case 0:
    $this->greet();
    break;
  case 1:
    // check_admin_referer( 'import-upload' );
    if ( $this->handle_upload() )
      $this->import_options();
    break;
  case 2:
    // check_admin_referer( 'import-wordpress' );
    // $this->fetch_attachments = ( ! empty( $_POST['fetch_attachments'] ) && $this->allow_fetch_attachments() );
    // $this->id = (int) $_POST['import_id'];
    // $file = get_attached_file( $this->id );
    // set_time_limit(0);
    // $this->import( $file );

    set_time_limit(0);
    $this->import($this->import_filename);

    break;
}

What we've done here is commented out the file import code and added code to call the import routine with our own filename that was defined earlier.

One more change: Find the function handle_upload() and update the first few lines so it looks like this:

function handle_upload() {
  // $file = wp_import_handle_upload();
  
  // if ( isset( $file['error'] ) ) {
  //   echo '<p><strong>' . __( 'Sorry, there has been an error.', 'wordpress-importer' ) . '</strong><br />';
  //   echo esc_html( $file['error'] ) . '</p>';
  //   return false;
  // }
  //
  // $this->id = (int) $file['id'];
  // $import_data = $this->parse( $file['file'] );

  $import_data = $this->parse($this->import_filename);


Just like above, we are commenting out all the file upload code and then forcing the parse action on our uploaded file.

Once your plugin has been updated, do the following:
1. Upload your import file into the wordpress root directory (again, where wp-config.php resides)
2. Run Tools -> Import -> WordPress.

At the first screen, do not select an upload file. Just click the Upload File and Import button and things will proceed from there. If your import file is extremely large, you may need to adjust some server settings (memory limits, timeouts, etc.) in order to process the entire file.

Instead I have a blogger export in xml format, converted it to a wordpress wxr file using the <a href=’http://code.google.com/p/google-blog-converters-appengine/’>Google Blog Converter</a>.  The resulting file is 48MB (about 3500 posts).  The WordPress wxr importer uses the standard wordpress upload system and limits the import file to 2MB.  This is a problem.

But it can be done…

After installing the wordpress uploader plugin (I’m using WordPress 3.1 by the way…), change to the plugin directory and edit wordpress-uploader.php.  Find the following method in the file:

/**
* Registered callback function for the WordPress Importer
*
* Manages the three separate stages of the WXR import process
*/
function dispatch() {

Further down in this method is a switch statement with three cases (0, 1, and 2).  Add the following code after the line containing: break; (at the end of the case 2 section):

case 99:
   $file = '../import.wxr';
   set_time_limit(0);
   $this->import( $file );
   break;

Save these changes and upload your import file to your wordpress root directory.  Make sure the filename is set to import.wxr.  Then navigate in the wordpress admin interface to Tools -> Imports -> WordPress.  The url should read something like:

http://domain.com/wp-admin/admin.php?import=wordpress

Add &step=99 to the end of this url and load the new page. The full url should read:

http://domain.com/wp-admin/admin.php?import=wordpress&step=99

It may take a long time for the page to load but that is normal as it is importing your content. Do not interrupt the process.

As with all free advice here, no guarantees and no promises to assist in the comments.  But this q&d (quick & dirty) hack saved me hours of breaking the import file into very tiny pieces.  Hope it helps someone else out there.

UPDATE:

This was the first step and got me started, but it bypasses some of the import step that is pretty important (linking authors for instance). Maybe someday if I ever have time (and someone wants it), I will post the rest of the changes I made to the original plugin.

Here is the app: Michelle Malkin. If you want to give it a spin. A good portion of my ‘free’ time for the last year has been spent on developing these two apps. The nice thing is that now I an past the learning curve and have experience serving wordpress content for both platforms. Now to see if I can sell some other bloggers on apps for their own sites!