By Quint on

What is the current state of affairs for upgrading or updating core and modules?

I really can't take this anymore. I like the fact that Drupal keeps up and reacts to the security problems, but after going through the upgrade process (on 5 sites) maybe 30 or 40 times, I've had enough. People that say it takes 2 minutes are being utterly ridiculous or reckless. The first site usually takes me about 2 hours, then the next ones take me about 10 or 15 extra minutes each -- so around 3 hours total. Fun fun.

Wordpress has an automatic updater -- both core and plug-ins. Why can't Drupal? I keep reading about security holes for auto-updaters. Does Wordpress have a security hole? I have to point out that it's a security hole to leave a site un-upgraded, too, since upgrading is a PITA, and one tends to procrastinate over doing it.

Assuming that's true that an auto-updater has inherent security holes, could some process on the local PC be built to log in with FTP or SFTP and do the upgrade? I use SyncBack Pro, anyway, to do all the file moving. Maybe someone who knew all the pitfalls of upgrading could develop something like that on top of SyncBack Pro or on WinSCP, if there really is some reason the server software can't be trusted to do it.

Seriously, I can't take this upgrading anymore. Is there any way to do this automatically? What about this Subversion thing, does that do it?

⋅ Categories: Drupal 5.x, Drupal 6.x, Drupal 7.x

Comments

ppmax’s picture

ppmax commented

I have to agree--upgrading and updating seems a little antiquated with Drupal. It would be great if I could check out a working copy of the core Drupal files from drupal.org then do svn update when a patch or new version is released. I realize Drupal.org uses CVS...

I have 5 sites (with staging sites for each) and it really is a PITA for a "serious" web developer...

yelvington’s picture

yelvington commented

Install Drush and upgrade from the command line. Very fast, very reliable, and -- unlike ANY tool you run from the Web interface -- very secure, as any files will be owned by the logged-in user and not by the HTTP process.

Quint’s picture

Quint commented

I saw that module, but it has the typical lack of detail in the description. So, ... how much of this is handled by Drush? ... thanks. These are my normal steps.

`
== BACKUP

run a database backup
zip the running file set

`
== PREPARE NEW FILE SET

download and unzip the new core distro
visit all my installed contrib module pages and review their new versions, and compatibility with new core version
download and unzip the contrib module updates
resolve any contrib mod problems, if necessary, like new dependancies

`
== REVIEW NEW FILE SET AGAINST RUNNING FILE SET

compare the virgin distro and new contrib modules file set to the currently running file set
delete install.php
review diffs of config.php
review diffs of .htaccess
be careful not to overwrite custom files
give up on customizing page templates because of this headache
review upgrade instructions for anything new

`
== USER AFFECTING STAGE

(here's where the pressure starts with the clock ticking)

`
== PREPARE THE SITE

put the site offline
print the page with all the enabled modules
disable all the contrib modules that are not locked
print the page with the locked modules
disable all the contrib modules that are no longer locked
set the theme back to default

leave a browser window up and logged in as #1

`
== UPGRADE THE FILESET

upload the new files

`
== UPGRADE THE DATABASE

run update.php
re-enable the modules, one by one, starting with the prerequisite modules
run update.php for each one (despite the "don't run update more than once" warning)
do a quick check to see if the module is working
leave the theme as default because it eliminates this step next time

`
== BACK ONLINE

put the site back online

`
== DOES EVERYTHING STILL WORK?

click around and test all the anon pages
log in
click around and test all the admin pages

`
== DONE

if it all works, phew, the clock stops ticking.

yelvington’s picture

yelvington commented

Backups: Drush will do a SQL dump of your database if you ask it to do so. Drush backs up your module folders when it downloads the updates, and it runs all the pending updatedb tasks in their proper order with a single command.

You don't need to disable and then re-enable all your modules one by one every time you update a module, or even a point release of Drupal core. You don't need to be comparing htaccess and config and install files unless you've been hacking them, in which case of course you're already responsible for a kitten and no amount of Web-facing automation is going to fix that. And you're not going to overwrite any custom files if you put them in the right places.

ppmax’s picture

ppmax commented

I should have mentioned that I use drush on all these sites. No doubt it's a great tool....but different and inferior to source control. In fact I'd prefer to use drush exclusively for modules--but employ svn for drupal core and my themes and custom modules.

izmeez’s picture

izmeez commented

subscribing; i'm another who is eager to learn a better way.

Quint’s picture

Quint commented

I just upgraded Wordpress again. I logged into my admin area and saw "Version 2.8.3 is available, click here to upgrade." I clicked it, and it took under 1 minute.

knytphal’s picture

knytphal commented

I'm with you - it would be so nice to be able to do the same in drupal. I dread upgrading a drupal site.

quentinsf’s picture

quentinsf commented

Yes, I have to agree...

I understand potential security issues here, but one-click updating works for Wordpress. I've fallen in love with Drupal and the update process is the one really painful bit of the love affair... :-)

dreamgear’s picture

dreamgear commented

and Amen.

What makes it worse is that the new management of my otherwise great host can't figure out how to run sshd on a high port with retries set to 1, so they have outlawed shell access unless you pay them a bribe.

anilgupte’s picture

anilgupte commented

How do we make enough noise to get someone to pay attention to this? Specifically creating a painless and seamless upgrade and rollback process. I am volunteering to do some work on this, but I am unfamiliar with the process.

Quint’s picture

Quint commented

Is there any progress on an automatic way to upgrade?

juan_g’s picture

juan_g commented

A related thread:

The current UPGRADE.txt lacks instructions for minor updates (6.x -> 6.y)

fehin’s picture

fehin commented

subscribing.

wavesailor’s picture

wavesailor commented

Drush only does modules and not the core .... I heard that auto-updates may happen in Drupal 7 - Is that true?

Quint’s picture

Quint commented

Is this true?

jrdixey’s picture

jrdixey commented

Hi Quint,

To clarify, 'drush update' updates modules, and then runs updatedb (which is the same as running update.php at the browser). To update core, you need to run 'drush dl' to download the latest drush, and then copy over just the files you want to overwrite your install.

This is the way I've done it:

drush eval 'variable_set('site_offline', TRUE)'

[puts site into offline mode]

Then you backup your site and database in whatever way you usually do it. I've read of ways Drush can help with this, but I don't usually use it for backups.

drush dl

[downloads the latest drupal core to its own directory, like 'drupal-6.15']

Then, delete anything from the newly downloaded drupal core that you wouldn't want to overwrite on your install (such as /sites, robots.txt, .htaccess ... anything in core that you have customized or added to). Copy over the remaining files from the new drupal directory to existing drupal core location.

drush updatedb

[runs update.php]

Assuming no errors, proceed to updating the contrib modules.

drush update

[updates contrib modules that require updating, then runs updatedb]

And, finally, put the site back online with

drush eval 'variable_set('site_offline', FALSE)'

I've done this a couple of times now (for minor version updates to core) and it worked fine and seemed like a lot less hassle than the normal way of updating Drupal and contrib modules.

Anyone with more experience is welcome to comment on or correct this of course.

Hope it helps,
Jennifer

exlin’s picture

exlin commented

I came up with similiar idea, i made post about it to http://drupal.org/node/717918 and i happened to read now this post also...