I have a Drupal website that's been sitting in mothballs for the last 4 years. When I go to the Drupal Available updates page, there's about 30 or 40 updates total listed there that show they need to be made.

A partial list of modules include:

  • Administration menu
  • Node clone
  • Content Construction Kit (CCK)
  • FileField
  • Forward
  • Mollum
  • Views
  • Webform
  • Zen

etc... There are a few more besides those, but those seem like the major ones. Note that I had the site built for me--it was an extensive undertaking--and I'm not even sure what each of the modules is for.

QUESTION: Can I skip all the intermediate updates and just install the very last of the various core and module updates? Or do I need to apply each update in sequence?

Question: Do I install the core updates first, and then the modules?

Question: If I need to update sequentially, are there dependencies for the modules and core such that I have to switch off--meaning, do a core then do applicable modules; then do another core, then more applicable modules; etc.?

There's a lot of work that needs to be done to update this site. I recognize that some of the back end will likely have to be tweaked to make sure it still works as designed. Can anyone give me an idea of the process and what it's likely going to take to get it back up to speed?

Two related questions:

  1. I want to move this site to a different provider. QUESTION: Do I update first and then move the site? Or do I install a new core and then move the site to the new core? (Obviously that will impact any module dependencies.)
  2. QUESTION: Should I move to Drupal 7 or 8? Is that introducing a ton of other possible problems that I don't want to get into at this juncture?

Thanks in advance for any ideas you might be able to offer in getting this site copacetic.

Comments

JamesOakley’s picture

Hi!

QUESTION: Can I skip all the intermediate updates and just install the very last of the various core and module updates? Or do I need to apply each update in sequence?

For each module (and for core), you can update all the way from the version you are on to the latest version. The procedure would be: (i) delete the code for that module entirely; (ii) upload the code for the latest version of that module; (iii) put the site into maintenance mode; (iv) run update.php through. The reason why you can skip intervening versions is that the update.php script will run any intervening code updates, so everything gets run,.

Please note: That advice is on the assumption that you are sticking with Drupal 6 - for now. If you wanted to update to Drupal 7, you'd be well advised to take core and each contributed module to the latest Drupal 6 version before starting a major upgrade.

Question: Do I install the core updates first, and then the modules?

I would, yes. And I would do one module at a time, too. That way, if anything doesn't work, you know which update hasn't worked, rather than having 30 updates going through at once.

Question: If I need to update sequentially, are there dependencies for the modules and core such that I have to switch off--meaning, do a core then do applicable modules; then do another core, then more applicable modules; etc.?

There's no need to disable certain modules. In terms of choosing what order to upgrade your modules in, I would do the dependencies first. So, if Views depends on CTools, update CTools first. It may be that the later version of Views assumes that you've already updated CTools, so you could get into trouble if you do them in the other order.

There's a lot of work that needs to be done to update this site. I recognize that some of the back end will likely have to be tweaked to make sure it still works as designed. Can anyone give me an idea of the process and what it's likely going to take to get it back up to speed?

There may not be much back-end tweaking (if you stay with Drupal 6). In terms of process, backup, backup, and backup. Before every step, take a new backup - without getting rid of the old backups. The backup needs to be your database and the file system. You want to be able to go back a step or two if any update doesn't work as expected. Fixing a site is much trickier if you've got a half-run broken upgrade in there, and no backup.

I want to move this site to a different provider. QUESTION: Do I update first and then move the site? Or do I install a new core and then move the site to the new core? (Obviously that will impact any module dependencies.)

I would move the site to your new provider as it is, and check everything is working OK. And only then try the upgrade. But if you want to do the upgrade on the old host, there's no reason why you shouldn't. It slightly depends what tools you get with the current and the new provider. It's probably best to upgrade everything on whichever host has the best tools for handling database backups, file backups, uploads, and so on.

I'm not sure quite what you mean by "a new core". When you move to the new host, just copy all the files across exactly as they are.

QUESTION: Should I move to Drupal 7 or 8? Is that introducing a ton of other possible problems that I don't want to get into at this juncture?

As I said above, get the site working on the latest everything with Drupal 6 first. If you want to upgrade, the next step is Drupal 7. Drupal 8 is not production ready, so don't even think of going there. If you wanted to, you'd have to go through Drupal 7 - that's one case where you do have to go one version at a time. But D6->D7 is a much bigger move than you're talking about, because some modules won't have exact equivalents etc.

One more thing. You mentioned Zen. That is usually only used as a base theme. Use caution updating that. You'll probably be fine provided you stick to the same major version (so don't go from 6.x-1.0 to 6.x-2.1 - just to 6.x-1.2). The chances are that your site's theme is a subtheme of Zen, and a major upgrade may make changes to the base theme that then mean your subtheme doesn't quite work as it does now.

I hope that helps.


This signature is currently blank
hamiltonian87’s picture

Thanks, James, for such good feedback/help. You've given me a sense of comfort I didn't have a few hours ago. For now I'll stick with getting everything to the latest 6.x...

As far as the "new core" was concerned, some providers like to install the app for you, then they take care of notifying you when updates are necessary. I've run into this with a client's WordPress site. So by "new core", I just meant having the provider install Drupal for me, then I copy the database, etc. over. My question/concern was simply whether it would be unwise to put an "old" implementation of a site into a newly installed current-version core. What do you think?

With regards to the procedure you list... QUESTION: "When I "delete the code" for a module before "upload[ing] the code for the latest version of that module", do I lose any settings? I'm afraid I'm going to have to re-learn how to add modules before I start working on this--I never added any before, though I was shown how it works at one point.

Thanks again!

VM’s picture

My question/concern was simply whether it would be unwise to put an "old" implementation of a site into a newly installed current-version core. What do you think?

The above won't work. An update to core isn't just the files. It's also the database changes that occur when update.php is run (when there are changes to the database). Thus if you do a new install of Drupal and throw the old database at the new install, you've a 1/2 updated site which will likely prompt the running of update.php again to perform database updates.

"When I "delete the code" for a module before "upload[ing] the code for the latest version of that module", do I lose any settings?

Settings are stored in the database. Thus, removing old code does not remove settings.

As an aside, make sure you obtain a database backup at strategic points in your update process.

JamesOakley’s picture

I'm afraid I'm going to have to re-learn how to add modules before I start working on this--I never added any before, though I was shown how it works at one point.

See http://drupal.org/node/70151


This signature is currently blank