Fixes include: some of the dahsboard widget options broken, few invalid Perishable 5G HTAccess rules, full backup was missing on wp-config.php if it was outside of WP folder and broken tweak for hiding help tab on top of pages. Big thanks goes to Alasdair MacGregor and Michael Dorman for testing and confirming problem with Sucuri Scan that wasn’t working if the Perishable 5G tweaks are applied that were preventing Sucuri scanner to access the website. Notice about this is displayed on Sucuri page if the tweaks is active.

As always, please report any bugs you find in the forums, and I will get on fixing it. As for new things, I am working on improvements to HTAccess tweaking, improvements to restore script to allow for more flexibility and few other features that will go into next two minor revisions.

Links and Resources

Here is the list of tutorials that you might find useful:

How to backup and restore your website
Using GD Press Tools 4.2 Backup
Using GD Press Tools Auto Tagger

Comparing GD Press Tools Pro versus BackupBuddy:

GD Press Tools Pro versus BackupBuddy

To see the list of plugin features, overview and to buy the plugin, visit these pages:

GD Press Tools Overview
GD Press Tools Main Page
GD Press Tools Frequently Asked Questions
Buy GD Press Tools Pro

Examples bellow are for WordPress 2.9 or newer. This is re-revised version of last years tutorial, this time with added meta info links block. New method is used that doesn’t require for you to check if the filter is executed for your plugin only. New filters already include plugin name in the filter name.

Additional options

Each plugin row on the Plugins panel has several standard actions. You can add more actions like the link to the settings panel or anything else. You need to add filter function that will be used to add this action(s).

<?php
add_filter('plugin_action_links_$plugin_file', 'add_plugin_links');

function add_plugin_links($links) {
  $links[] = '<a href="index.php">Dashboard</a>';
  $links[] = '<a href="edit.php">Posts</a>';
  return $links;
}
?>

Lines 5 and 6 are adding new action to the plugin row. This example adds link to the dashboard and to post edit page, you can change it to whatever you need. Don’t forget to return $links because this is a filter not an action.

Very Important: On line 2 filter has $plugin_file. You need to replace this with the relative path/name of the main file of your plugin. For instance, my plugin GD Press Tools has a $plugin_name: gd-press-tools/gd-press-tools.php. It has folder name, slash, main plugin file name (with extension), and full filter name will be than: plugin_action_links_gd-press-tools/gd-press-tools.php. Same method will be used in the last expand examples.

Plugin Meta options

Description column in the plugins grid have also number of links. This can be expanded similar to additional options from previous block.

<?php
add_filter('plugin_row_meta', 'add_plugin_meta_links', 10, 2);

function add_plugin_meta_links($links, $file) {
  if ($file == "$plugin_name") {
    $links[] = '<a href="index.php">Dashboard</a>';
    $links[] = '<a href="edit.php">Posts</a>';
  }
  return $links;
}
?>

Lines 5 is there to ensure that you add settings only to your own plugin. Lines 6 and 7 are actually adding new action to the plugin row. This example adds same links as previous one, but, you can add whatever you want leading to your own plugin. In the case of this filter, you must check on your own if the filter is run for your plugin.You must $plugin_name on line 5 with the string as described in the first example above.

Additional plugin info

WordPress shows description from your plugin file. And when the new version is available for update, there is no detailed info about the the update. Adding that is not very hard.

<?php
add_action('after_plugin_row_$plugin_file', 'add_after_plugin_meta');

function add_after_plugin_meta($file) {
  $current = get_site_transient('update_plugins');
  if (!isset($current->response[$file])) return false;

  $url = "http://www.yoursite.com/info.txt";
  $update = wp_remote_fopen($url);
  echo '<tr><td colspan="3">'.$update.'</td></tr>';
}
?>

Function checks to see if you add row to your plugin as the previous function does. Lines 5 and 6 will check if there is an updated found for your plugin. If no update is found, additional row will not be added. You can remove this part, and added row will be always visible. My intention with this code is to display details about the plugin update, you can change it to anything else. You need to echo only TD part of the row, WordPress already echoes TR tag. Function will get contents of the file from $url variable and will echo that file in the row.

Example

Example above shows both functions used in GD Press Tools plugin. First row is a standard plugin info, and you can see Settings action added by first function. Second row is WordPress info that plugin upgrade is available. Third row is info displayed by second function that has retrieved this changes notice from my website.

This example uses same $plugin_name method that is described in the first example.

I made few changes to each of the WP installations so that the measuring rendering time is more accurate. Also, I changed few things in GD Press Tools also, and the Arthemia theme for the next part when the benchmark will be done for the actual blog. For some of the plugins I used older versions for WP 2.6.5, as recommended by the plugins authors. All results displayed on the charts are mean value from 5 measurements. I used Opera 9.64 browser for time and memory tests, and Firefox 3.0.11 with Firebug 1.3.3 for size of the output (personally I don’t like Firefox at all).

For test configuration and setup check the previous post: Benchmark Setup. On all 3 charts, first 3 columns for each page is for WordPress without plugins (only GD Press Tools is active), and the next 3 columns are for WordPress with all 15 plugins active, list of plugins in setup article.

Why benchmarking?

The reason I made these tests is because it’s obvious that no one in WordPress development team didn’t do anything like this. In fact they even claimed that WP 2.8 is much faster, and that’s simply not true at all. Take a look at this page, and notice that one of the highlights is speed of the admin pages. Speed can be gained using Turbo with Google Gears, and in that case browser needs less time to render the pages. But Opera, Safari, Chrome and Firefox are very fast already and will render very fast anything you throw on them. Browsers can’t speed up server response time. And Gears is not an option for Opera or Safari users (hopefully we will see better Gears browser support soon), not to mention problems I had with Gears in Firefox and that I don’t plan to start using it any time soon.

WP 2.6.5 is used only as a reference, in most cases you can’t really compare it with WP 2.7 or WP 2.8 because interface and some other things are rewritten, but it’s interesting to see how WP 2.6.5 compares to latest releases in terms of performance.

Page load times

First series of tests are to determine how much time PHP and server needs to generate a single page. Some of the things were problem to measure with WP 2.8, but I will get to that later. Even when the pages are partially loaded from cache this time is more or less the same. I noticed some 10-20% drop in WP 2.8 for reloading the same page, but that’s still too high.

WordPress load times

WP 2.8 is more than 2 times slower than previous two WordPress versions. On some pages difference is even bigger. I have measured 4 pages, 3 are WP native pages, last one is Settings panel from GD Press Tools, and it’s the fastest in the group because it doesn’t load a bunch of things most WP pages do.

But, there are some pages that need much more time. General settings page takes more than 10 or 15 seconds to load, because for some reason WP developers decided that the time zone list needs to be populated from WordPress website. This list could been included in the WordPress code. Right now it gets really frustrated to change any of these settings and need to wait all that time. That’s simple unacceptable.

Used memory

Things are pretty much the same with memory usage. As you can see 15 plugins add a lot to the memory used. WP 2.6.5 uses much less memory in both cases but that’s not a big surprise.

WordPress memory usage

WP 2.7 and WP 2.8 have totally rewritten interface and because of that it needs more memory. But the problem is with WP 2.8 that more or less should have the same memory usage as WP 2.7 because the changes were not that significant to cause this difference. Dashboard is the biggest problem and it uses some 25% more memory than WP 2.7. On some pages like the the general settings I mentioned earlier in some cases I noticed memory leaks and memory use increases to 45-55 MB. On one instance loading failed meaning that it exceeded preset 64MB. And again, that’s most likely caused by the timezone code.

WordPress output size

Page size

Finally this is something where WP 2.8 is actually better than WP 2.7. Again, WP 2.6.5 pages are smaller because of the different front end, but it’s interesting to see how much the interface ‘costs’.

WP 2.8 generates smaller pages compared to WP 2.7 mostly because of better optimization of JavaScript and CSS loading and joining several files into one. And in the same time that’s one of the reasons for slower loading and increased memory usage with WP 2.8.

Conclusion

There was a discussion on Weblogtoolscollection website about using 1 or 100 plugins, and it’s obvious that number of plugins active will increase used resources and time needed for page to be rendered. Another post that will investigate this much deeper. It will take some more time to prepare but it’s coming soon.

Based on all this is clear that in terms of speed and memory usage WP 2.6.5 administration is much better than the latest WP versions. On the other hand these are not actual pages that blog visitors see, and next post present results of blog benchmark under same condition, so I am not going to give some definitive judgement right now. I know a lot of people that still use WP 2.6.5 because they can’t increase memory every time WP is released. When WP 2.8.1 is released I will do a benchmark against current WP 2.8, to see if indeed developers managed to solve memory usage increase and lower speeds.

I use WP 2.8 on all my blogs right now, but I must say that I am not happy with performance of the administration compared to older versions. Interface IS much better, and to some point I understand and accept that the performance is a trade off for the interface and better work flow. But only to a point. I will be very disappointed to see WP 2.9 some 7-8 months down the road that instead of 40MB needs 50MB or more to work.

So, tell me what you think about data presented here, and about your own experiences with last 3 versions of WP, and especially with WP 2.8. And stay tuned for more benchmark results.