My blog runs on Tumblr. Why?

Because when I have a couple of hours to do something with it I'd rather write instead of updating a shit load of modules and debugging problems.

Having this work would make me consider switching my blog back to Drupal.


simg’s picture

Couldn't agree more, but this does sound like an issue which should (eventually) be addressed in core Drupal ?

I'd also add "Make incremental backups" happen seamlessly. These two issues together are the biggest maintenance costs of running a Drupal site (especially if it isn't being actively updated) and whilst necessary are completely not understood (and therefore valued) by customers.

RobLoach’s picture

I remember seeing the Drupal core issue to upgrade during cron, but I can't seem to find it. Seems like something update.module could do if it were in contrib.

dww’s picture

update.module can certainly help with this. However, the limitations in that module aren't because that's part of core. update status used to be in contrib, and was consciously moved into core to ensure that the widest possible number of sites have access to that functionality. Maybe in the new direction people are pushing for more viable distributions (aka "Drupal products") we could consider moving it back into contrib on the assumption that all products/distros will include it, but that still seems to be a long way from being reality. Moreover, I wouldn't have any more time to work on update manager if it was in contrib. ;) And historically, it's been very hard finding other people interested in working on it (since the vast majority of us qualified to work on it never use it for ourselves preferring other tools like drush instead).

However, more to the point, the problem of "seamless" updates isn't confined to the technology doing the updating. The thing that makes "Software Update" Just Work(tm) on your Mac isn't that their installer itself is particularly bullet-proof. It's the fact that Apple has a bazillion people working full time on all the new releases of stuff that Software Update copies down to your machine to ensure that everything works every time and it all goes seamlessly. And even with a well-paid army of developers, testers, QA engineers, project managers, release managers, devops people, etc, it's still not perfectly flawless and occasionally they break stuff. Contrast that with the state of Drupal contrib. Overwhelmingly volunteer driven, with wildly different coding abilities, QA standards, practices, release management styles, etc. It's such a completely different universe from the one in which Apple's Software Update works that it's not even relevant to compare. ;) So, I think it's ultimately folly to believe this can be solved by automated updates (heaven forbid they happened on cron!).

The best hope for something approximating "seamless updates" would be if we added distribution support to the update manager, so that it didn't necessarily offer to upgrade the parts of your distribution individually as they become available, but instead offered to upgrade you when a new version of the distro itself comes out. Presumably that means the distro maintainer did some kind of QA to make sure the new combination of versions of all the dependencies actually works. However, Drupal itself doesn't currently handle "updating" a distro, so there's a *lot* of work that would have to happen to make this a reality. Certainly we could put effort into some update manager specific stuff so that you *only* got the new versions of core, contrib, and it ran update.php for you on all those modules. That'd probably be 80% good enough, so we should discuss that (elsewhere -- I don't remember ever proposing this before as an official issue, but maybe there's one already open I don't know about). Also, given the importance both Dries and webchick put on distros, I don't think it's insane to believe that if a real push went into making update manager distro-aware, we could potentially back-port that into D7 core. But again, that's a discussion for a different issue (unless we move this one into the update manager queue and re-purpose it).


p.s. Hurray for this distro/product. I'm really excited to see this taking shape! I loved sun's Drupal planet blog post about it.

Grayside’s picture

Not to hijack the issue to talk about update status, but I thought it was relevant to mention one solution in the wild:

The Common's approach is a module whose updates secretly correlate to the version of the Distro as a whole. When this module is enabled, it wipes every other Commons module out of the Update Status tracking.

As a Drupal person running a Drupal blog, one of the important things is knowing when the module updates don't need to be made. If it ain't a security issue, there's not reason to change what's working.

rlnorthcutt’s picture

D7 has the ability to update modules through the UI, with notifications on this. No updates for core through the UI as far as I know.

But - since we don't know exactly which modules a user may have, or how contrib modules may change (and possibly break) in the future, I don't know that including auto-updating is a good idea. People could end up with broken sites or broken features after an auto update, and not know why.

Also, the plan here as I understand it is not to write any code, per se... simply to create an install profile (distro) that relies on core and contrib. If there IS enough traction to implement an auto-updating type feature, then I think it should be done as a separate contrib module that would be included.

However, I think most people are happy with the UI updater for contrib and with Drush for easy updates all the way around.

Grayside’s picture

Now that distros are part of the fabric of D.O, "seemless updating" could easily be covered by accessing the distro's drush_make file and using that to pull down updated module versions. A well-defined Distro should be using specific module versions for each tagged release.