For The Case of WordPress, Against Self-Indulgent Promoters Who Were Hacked

Last weekend was filled with controversy and the reason for this was a worm hitting many self-hosted WordPress blogs. We warned and urged everyone to upgrade, although the most recent version of WordPress, 2.8.4, was released almost 3 weeks earlier. WordPress 2.8.4 was the second security update for the 2.8 branch in less than 2 weeks. This update was released only 2 days after the vulnerability was discovered, proving how hard the WordPress community has worked to improve and secure the platform.

Ever since WordPress 2.3, which was released almost exactly 2 years ago, every WordPress blogger receives an update notification whenever a new version available is. The majority of new releases are bug fixes and security updates.
Personally, whenever I see that yellow new release notification I can not hit update now fast enough. If it weren’t for the security aspect then it is for the ugliness of the notification.

Nevertheless, in these days some people are given a megaphone online and can not resist the need to be vocal, even though they were the only ones who were to blame. One of these people last weekend was Robert Scoble. His post I don’t feel safe with WordPress, Hackers broke in and took things quickly went viral Robert received support but also bashing. Gruber even went as far to say that Movable Type safer is.

Regardless whether MT is more secure, it is clearly safer.

I have criticized WordPress in the past and will continue my search for alternative platforms, but this time I have to defend the WP community and Automattic. WordPress has done everything right.
We certainly can argue lots about whether WordPress a safe engine is or not, but statements like Michael Gray‘s tweet some days ago are what we tend to call BS:

if wordpress was serious 9am tomorrow morning stable secure code would become priority #1 … not features to amuse programmers

I will repeat myself: WordPress/Automattic has done everything right. WordPress is highly optimized to make update hell easier for the blogger:

1. Notifications about new releases
   Not once, usually you can see at least 3 different notifications: at the top of the admin back-end all-over wp-admin, on the wp-admin/index.php page you will probably see at least 3 feed entries mentioning an update (Dev blog, WLTC and Andy or Ryan). Upgrade notifications have been implemented since September 2007 (WordPress 2.3);
2. One click upgrade
   WordPress comes with an upgrade feature for both the core platform and plug-ins since December 2008 (WP2.7). To please pedants, I will admit that it’s a two-click update. ;)
3. Security releases come quickly when they are needed.
   The above mentioned 2.8.4 relases is the proof of this

But both WordPress and the upgrade feature aren’t failsafe. The argument that plug-ins aren’t compatible and could break an upgrade should not prevent users from upgrading:

Been asked what I thought about Scoble/WP: NEVER put an addon over the SECURITY of your CONTENT. Put your content 2nd, you’ll get hacked. [via @tyme]

There are several things which could be improved to makes upgrades (feel) safer and even easier for users though:

1. Automated database backup
   Instead of displaying a notification that users should update the database, this feature should have become a core feature ever since the automated upgrader was launched. Instead we recommend WP DB Manager (WP DB Manager tubetorial video) or use a cron job if you do not want to rely on a plugin. Optionally the backup procedure should also offer to backup the WP files;
2. Deactivate the plugins
   The second recommendation from the WordPress Codex page on upgrading is to deactivate your plugins. Maybe this should be build in and after upgrade the user should be offered to reactivate them. Better would even be if there were a compatibility check built-in;
3. Force plugin hooks to check if the plugin is activated after upgrade
   I am no coder but would assume it would even be possible to require a hook or API to make plugins check for the use of if (function_exists()). This would ultimately prevent that themes would break if the upgrade deactivates plugins.
4. Plug-ins with customization options should adopt a ‘child themes alike’ structure
   Many plugins come with the option to change the CSS or have different options. Several write these in the database, other overwrite the original CSS file on the server. Other plugins still require hacking of the core plugin files. In the latter case the changes will be overwritten whenever the plugin is updated. Plugins should adopt a similar structure to child themes, allowing the user to revert to the original plugin structure whenever customization went wrong, all while keeping the changes after updates.
5. Separate Admin back-end from front-end

There is not one single reason one can think of why the admin area should be in a standard folder. Automattic, change this now and also offer those who want to an easy option to install the admin area on (shared) SSL space.

To Robert Scoble I only have to say that it’s time he finds a hoster with daily/weekly/monthly automated backups. :)