One of my favourite things about Drupal is that it offers theme and module developers the ability to use dependencies. A few simple lines in the module.info file (Drupal’s sort-of readme.txt equivalent) can specify that the module depends on other modules and Drupal will recognise that, offering to install and/or enable those modules for you in order to meet those dependencies. E.g.;
dependencies = views dependencies = rules dependencies = features
That’s not all though, Drupal also allows module developers to specify required libraries in a similar way. Those libraries are then installed in a ‘libraries’ directory alongside the modules directory.
By contrast, WordPress plugin and theme developers often have to bundle those libraries into their plugin or theme. The result, when a security issue like yesterday’s TimThumb exploit is revealed, is that individual plugin and theme developers need to update their projects individually and push out an update, leaving users vulnerable until the developer gets round to it.
Instead, having a system like Drupal’s dependencies means that, once the library itself is updated, all installations could pull down that library update and secure their site without the plugin/theme developer having to lift a finger. Installs are secured quicker with minimal effort.
There are other benefits to a dependency system but I believe the security angle is by far the most compelling.
My suggestions above actually go a bit further than what Drupal offers at the moment, I believe, but a system that works as close to the plugin/theme system as possible would be beneficial.
Before you say it, yes, there is a better way to deal with TimThumb specifically. David Bisset put it best:
Picture credit: The Colorful Library of an Interaction Designer by See-ming Lee