Do We Have To Put Corks On All The Knives?
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!
I disagreed with this change, too.
But Morten has recently pointed out that voting doesn't work :P
I don't see why the collapsed fieldset was a problem. It follows the same pattern as operating system updates, for example. The OS will say "Hey, there's new stuff! Should I install it?" and you can click Yes or No. But there's always a "See the dirty details" option that lets you see (and usually opt out of) all the little things that are going to take place.
Anyway - I agree 100% with Greg Harvey - this "UX" improvement is a severe "DX" regression.
The cork stays on the fork
See the original gag.
That said, I guess we need a contrib UI to put this back, because I use it all the time.
Drupal core
If 90% of users do not need something then it should not be in core. Simple like that..
If an update does not work, then it is a bug, and should be fixed. No need for workarounds.
Bah!
Firstly, 100% of developers need this. Secondly, waiting for bugs to be fixed in some hook_update before you can safely apply latest versions is not practical. We all know contrib bug fixes can take *months* (or longer).
100%?
Firstly, 100% of developers need this.
I am a developer, and I do not see why would I need this. And I think the brave users creating the original patch are developers also.
I used this option once, when I was testing the D5-D6 upgrade of my module. Never used it since then.. So next time when I need it, I will happily use a contrib module..
Contrib bug can be fixed as fast as you want it to be fixed..
Yes, 100%
No one uses it much, but you've used it, so that rather proves my point.
And as regards your comment about contrib bugs being fixed quick, we fix things when we have time - sometimes we just have to prevent an update from running and worry about a *fix* later. You must work in some perfect world if you have time to drop everything and start fixing bugs on a whim, as and when you come across them. I do not have that time and neither do most other people.
100% of developers are not
100% of developers are not 100% of the users of Drupal. I think this would be fine for devel.module. I'm a co-maintainer on it and if I can't get to it first, I'd be more than happy to review patches for this functionality.
Completely agree
Agreed, this should be in dev and not core. For those who want the functionality, right a patch and submit it to Dave!
And the administrator?
There is another interesting demographic emerging in the comments here too, that I hadn't thought of and the people who advocated dropping the update.php drop-downs certainly hadn't thought of.
It seems there are a lot of Drupal administrators out there. Sysadmin folk, people looking after their own sites, some technical, some less so, but they are all *not* developers. The can't write patches or fix issues, but they do install modules and they do sometimes find the drop-down interface useful - they're saying so, right here. I suppose it's fair to say "they can install Devel then", but I still don't think they should have to.
But a consideration?
I never said they were. But we are *a percentage* of Drupal users, a fairly large one, and we seem to be losing out sometimes when the UX changes over-reach. That's my opinion anyway.
I'm happy for the UI to be in Devel too for now, but I think there are two points to consider:
1. the point I made in my post on d.o about splitting the logic from the UI - this is a code management nightmare waiting to happen. Why have the logic for incremental updates in core and the UI in devel? They should live together.
2. Rob's point about the Drupal 6 behaviour being *absolutely normal* for nearly all software you can think of. An advanced UI is fine. Why change it? It's water under the bridge now, but I doubt you'd advocate the idea of the ability to review updates in Windows as something Microsoft should sell you separately for $50 on its own CD, nor would you say it's not a core issue. =P
Anyways, all that stuff aside, appreciate the patch offer and I'm pleased there will at least be a UI in Devel. If I get chance I will also happily create this patch, but I've another crowded week ahead, so it won't be happening in the next few days from my end, that's for sure.
And drush isn't a solution...
Further, saying that "it can still be done in drush" isn't a solution. I've never learned to use it, and I suspect I'm in the wide majority among Drupal administrators. If an update fails, I don't want to have to (1) figure out that drush will solve the problem, (2) install it, then (3) hastily learn how to use it just to get my site back up.
In short, I'm agreeing with you. :)
I agree
I remember when this was first being talked about on IRC and I objected to it, then. The answer, as usual, was that it can be added back in contrib. Maybe it could go in as part of devel?
Michelle
Post new comment