By bserem on

I've been using SMF Simple Machines since 2004 and after 4+ years since the "first contact" SMF still amazes me with it's upgrading system. Everything happens from inside it's administration panel, you don't download and you don't ftp anything to the server. Tests are being run to prevent prossible errors (doesn't happen often) and in a matter of 5 clicks you are ready.

This works for the core system (SMF) and for all the addons!

Can something like that be implemented in Drupal? It's not that I find drupal upgrading difficult (although I am not used to it yet), but compared to SMF it think it lacks on many areas... Just my impression after a month with Drupal.

What do you people believe and what do developers believe?

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

Comments

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
commented

This sort of automated upgrade system has come up many times but always runs into the problem of how to let Drupal modify its own code without introducing security holes. I haven't kept up with any of the projects working on it so no idea how close they are. If you do a search, you'll probably run into them. This is one of those endlessly debated things.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

tf5_bassist’s picture

tf5_bassist commented

Hmm... Howabout just making an upgrade process that doesn't suck? There's a good start. The ridiculous hoops that must be jumped through in order to upgrade an install of Drupal is really making me regret using it. And as soon as I upgrade, a week later I have to upgrade AGAIN.

I'm now seriously debating going back to wordpress. I don't want to, but damn...

jtjones23’s picture

jtjones23 commented

With Drupal 6 (say 6.8 to 6.9), I delete the old files (except for the sites folder), upload the new files (again, not the sites folder). Check the status update page to see if update.php needs to be run and I'm done.

brian_c’s picture

brian_c commented

You are skipping a lot of steps in UPGRADE.txt, such as disabling all custom and contributed modules.

I upgraded 6.6 -> 6.8 recently, and this was the most painful part... especially since disabling all modules requires multiple passes due to dependency issues, and you need to keep track of exactly which modules you need to re-enable after (and my site uses a LOT of modules).

There's other things it suggests too, such as placing the site offline and switching to a core theme.

Even if it's not fully automated, it would be nice if Drupal had some sort of "upgrade mode" you could place it in, that would go offline, switch themes, and disable all modules. When you exit "upgrade mode" it would automatically restore all of this and prompt you to run update.php.

That would go a long way to making the process (as instructed) smoother.

juan_g’s picture

juan_g commented

brian_c wrote:
>You are skipping a lot of steps in UPGRADE.txt, such as disabling all custom and contributed modules. I upgraded 6.6 -> 6.8 recently, and this was the most painful part... especially since disabling all modules requires multiple passes due to dependency issues, and you need to keep track of exactly which modules you need to re-enable after (and my site uses a LOT of modules).

I think the current UPGRADE.txt is unnecessarily complicating the lives of many webmasters, and should be completed. It does not clarify that those are instructions to upgrade between major versions (5.x -> 6.y), and not between minor ones (6.x -> 6.y), which is a much more frequent and much simpler procedure. Acquia Drupal's Getting Started (a PDF in their downloads section) is clearer and detailed about this.

See also for example the following useful clarification by VeryMisunderstood:

I also state that you don't have to disable any modules because you are only moving up a minor version. You only have to disable modules when you are moving major versions. ie Drupal 5.x to Drupal 6.x because drupal 5.x modules will not work with drupal 6.x thus disabling them is a best practice as they will have to be upgraded too.

Going from 6.8 -> 6.9 is as simple as
put site in offline mode
back up your DB and files
delete all files and folders except the sites folder
upload all 6.9 drupal files and folders from 6.9 except sites folder
run update.php

The only files you will need to replace in drupal, is your robots.txt and your .htaccess. You only have to replace them in the new install if you've customized them.
brian_c’s picture

brian_c commented

Thanks for the clarification.

UPGRADE.txt definitely needs to be re-written if that is the case, it specifically implies that disabling/re-enabling modules is required for every type of upgrade, the only difference mentioned is that for major upgrades you will need updated modules.

philbar’s picture

philbar commented

I believe it is assumed that "upgrade" implies major versions D5 to D6 and "update" would be 6.x to 6.y.

Hence the reason we have update.php rather than upgrade.php.

brian_c’s picture

brian_c commented

update.php is used for both minor and major upgrades, and the word "upgrade" is used interchangeably in the documentation (ie UPGRADE.txt, and http://drupal.org/upgrade) to describe both major and minor upgrades. So I don't believe that assumption is valid.

HaloFX’s picture

HaloFX commented

I have been playing with Drupal 6 for a little over 6 months, but have just got serious with it in the last 6 weeks. Before I was playing and would just nuke the install and reinstall, didn't have any valuable content yet. But now I have 5 sites in a multi-site, and 10-12 more to go, and find the upgrade a bit daunting. This is rather odd, since so many other aspects of Drupal seem to be so well thought out.

Several other CMSes I have used have had much better upgrade paths. e107 publishes just the changed files in the update file. So you know exactly where to look for conflicts. The site is taken off line, and the new files are copied over the old and then the update script runs and updates database if needed. It is much more direct. The SMF approach is even better.

Like a previous poster mentions, I don't always remember where changes have been made. Some sites I am actively involved in, others I build and hand over to the client. I try to keep documentation, but that doesn't always happen.

This upgrade process is making me really give the multi-site a second thought. It sounds great and has been till today. Now I think I should only use multi-site for testing and development and then roll the production sites out on their own installs, so I can deal with them as time or priority dictates. However, having a couple dozen separate Drupal installs running on the same host sure seems wasteful.

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
commented

"I don't always remember where changes have been made."

All your changes should be under the "sites" folder, which you don't replace. There are occasionally other changes needing to me made, like copying a newer version of jquery into misc, but those should be so rare that it shouldn't be hard to keep docs on them.

The Drupal upgrade process may be a bit more tedious than a click on a website but it's certainly not difficult.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

bserem’s picture

bserem commented

a different update procedure would also help with module installation (again, just like SMF) and module upgrades

now to upgrade (or install) a module you have to download it, then ftp it to the server, stop the old version, install the new version etc etc etc

the SMF approach is simple: click install, click next if no errors found and ta'dah! ready to go

--
http://srm.gr - Drupal Implementor

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
commented

You don't have to do it that way. This is what I do:

* Open update status page
* Open putty to module directory
* Open release notes in new tab to check for gotchas
* Right click link to tar and copy
* Click on putty
* wget shift-insert
* rm -rf old dir
* tar -zxvf tar file
* Repeat for next module

It's not quite as quick as clicking an "upgrade me" link but not difficult, either. Took me longer to type that up than it does to upgrade a module.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
commented

I brought this up on IRC to get answers from people who know more about it than I do. What it boils down to is people need to give some loving to http://drupal.org/project/plugin_manager and get it in core. So if you care about this issue, go help out there. Test, give feedback, patches if you can.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
commented

Here's the link to the issue for upgrading Drupal core within plugin manager:
#330107: Automate drupal upgrades?

It needs lots of help from contributors to get it working.

bserem’s picture

bserem commented

thank you both!

I'll definately look it (installing it now) and although I don't know PHP I'll to do the best I can

--
http://srm.gr - Drupal Implementor

tf5_bassist’s picture

tf5_bassist commented

If there's a plugin manager, I'm game for testing it out. If I could develop, I'd help. I can test the everloving cr@p outta' it though.

And I should probably say this, since between my last post here and today, I've just finally played with Wordpress 2.7 and, I have to say... The most effortless upgrade process I have ever seen. Upgraded from 2.7 with customized themes, no issues whatsoever. And now it has the built-in plugin installing/upgrading/etc... This is where Drupal REALLY needs to shine. If WP can do it, Drupal needs to do it better to steal some of that thunder.

I'll check out Plugin Manager when I get some time, thanks for the linkage Michelle. :)

Michelle’s picture

Michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Testing helps, too. :)

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

bserem’s picture

bserem commented

I'm already checking it out and I love it!

Especially with alphas and betas that have a new release every two days it helps very much...
Spread the word :)

--
http://srm.gr - Drupal Implementor

domesticat’s picture

domesticat commented

There's another option worth pointing out, and I'm surprised it hasn't come up here.

Are you comfortable working from a command line?

If so...

For modules: have you tried installing the drush and drush_extras modules? Paired together, they allow you to perform module upgrades from the command line. MUCH less painful and far faster.

For core: I just migrated over to upgrading via CVS and it was absolutely worth it. I have not done a major-version upgrade yet, only minor-version upgrades, and if your site was set up using CVS the process of upgrading can be as simple as firing a single line. See http://drupal.org/node/93966.

I just [this morning] finished the process of moving three drupal installs that weren't originally done with CVS, to CVS, so the process is fresh in my mind.

modctek’s picture

modctek commented

I would totally go the CLI route, except I can't for the majority of the sites I manage, as shell access isn't possible.

I am totally looking forward to Plugin Manager 2!

rsvelko’s picture

rsvelko commented

Quote: "I would totally go the CLI route, except I can't for the majority of the sites I manage, as shell access isn't possible."

Whenever you have no shell access do the following:
1. Put site in offline mode.
2. Clear caches (optional here, but good to be done at some point, sometimes it halves the database export size)
3. Do a database backup (via phpmyadmin/hosting cpanel/ or remote mysql if possible)
4. Zip the whole drupal folder (via hosting cpanel or sth...) and download it (or copy the folder via ftp, which is much slower)

5. Restore files/DB on a server where you have shell access and use drush there to update. Then backup that new site's files/DB .

6. Put your updated site on the server replacing the older version (whose backup you made in steps 3,4 and keep that for a month after that just in case)

7. Check permssions of sites/default/files if for some reason they have changed while copying pasting around

PS. The process is logical and easy to do. The part with "drush pm update" is real candy :)

PS2. For those who do not have access to a linux box where to use drush - you can set up linux in a virtual machine (VMWare, VirtualBox ... see wikipedia for a list) and run it on your laptop for example...

PS3. Now I remembered that there were several backup drupal modules that can speed up the backup part... and maybe even the restore part but that would be unsecure I guess... to let a drupal module do a file and db restore to your filesystem and db server...

toddgee’s picture

toddgee commented

I wrote a vast script library that makes Drupal deployment and update a snap.

See the library at toddgee.com/drupalScripts See esp, the script drupalCVSDeploy.sh: http://svn.toddgee.com/drupalScripts/drupalCVSDeploy.sh

All scripts have lots of built in help and leverage the very highly specified deployment layout to do lots of cool things. Of course, this all assumes you have access to a command line; but if you do, Drupal administration is made much easier.

And yes, I know about Drush and have used it. I use it especially for the update task. For everything else tho, my scripts work better (IMHO)
see more at toddgee.com/drupal