Do We Have To Put Corks On All The Knives?

Photo of Greg Harvey
Sun, 2009-10-04 12:54By greg

Yay! My first blog post with the 7.x tag! It's coming up fast, folks... Shame this one is a gripe.

Courtesy of an issue I raised some months back regarding the update system registering updates in the system table, even if they fail, I came across an interesting and (IMHO) bad decision regarding update.php in Drupal 7:
http://drupal.org/node/595550

Because of newbie confusion about the various module updates and the myriad of drop-downs on update.php, it was decided to completely remove the advanced bits of the UI for updating modules from Drupal 7. I don't know about anyone else, but I have *needed* that feature on numerous occasions, so for me this is a step backwards in usability from a technical perspective (even if it's a step forwards for the novice).

Don't get me wrong, I'm all in favour of the UX improvements in Drupal and they are mostly necessary, but you can't wrap everything in cotton wool. Especially stuff that, by its very nature, is contributed, not always well written and prone to failure.

Sometimes contrib developers screw up and a hook_update implementation fails. Sometimes that failure is completely unforeseen and only occurs when a particular set of modules are installed. Sometimes you find that a failure is purely down to the *order* of updates (I've had that before) so the ability to run one set first and then another set is necessary. Regardless of the specifics, in this case the ability to exclude an update, for advanced users, is crucial.

Apparently all the logic is still there in core, it's just a UI change. Drush will still, therefore, be able to do db updates one by one, if necessary - but what if command line access is not available? And yes, the UI could be reinstated by a contrib module, but why? This is a *core* issue.

I propose a module is added to the core package, called something like Advanced Update UI, disabled by default (think PHP Filter in Drupal 6) but there so that advanced users who need fine-grained control over the update process can still have it.

And please, can we leave a few useful tools in the kitchen! Drupal needs to be as usable as possible for *everyone*. Don't forget developers need to be able to use it too!