We Need an upgrade module or something.

I got this big surprise this morning 6.16 Drupal released.

Currently, I maintain 19 Drupal sites.

Some have a large number of 3rd party contributed modules.

It takes most of the day to upgrade all the sites.

Disabling all the 3rd party modules, changing the theme to a default theme, backing up the sites directory, go into Cpanel, identify the database and users then I backup the Mysql, etc.

We really need more efficiency for upgrading.

I hate upgrading, because if I leave off something on production site it can take hours to fix a few screwups.

HELP! I would appreciate, if we just had a module that would disable all the NON-CORE modules, this takes alot of time because most have child modules requiring
unclicking and submitting many times.

Comments

VM’s picture

minor upgrades don't require modules to be disabled or themes to be switched. Major upgrades do., ie 6.x to 7.x

upgrading is a nature of the beast.

domineaux’s picture

Did I miss that in the upgrade readme? NOPE, item 4 and 5 plain as the nose on your face

4 - If using a custom or contributed theme, swtich to a core theme, such as Garland or Bluemarine.

5 - Disable all custom and contributed modules

I really do appreciate your response, and I don't mean disrespect... but I don't know who you are or if you know what you are talking about.

I have a document that indicates how do to the upgrade, and I have thousands of hours of work in the 19 site I have to maintain and upgrade.

Sorry, but someone needs to make an officious declaration about what you said. I would absolutely LOVE to do what you say.

I've been doing my best to follow the upgrade instructions to the letter, since Moses crossed the Red Sea.

muhleder’s picture

I follow the same process as VM, but I do test locally first. Upgrading 19 sites probably is going to be a pain though tbh, unless you have some sort of automation set up. Putting a site offline is probably a good idea, backup migrate module is good for grabbing a quick backup without having to login in to cpanel or whatnot.

domineaux’s picture

I gave up on the backup migrate module some time back. I had some serious issues with it. Not that it isn't fixed now.

I use PHPADMIN for export all Mysql and then I FileZilla all folders down to a Webserver Backup folder on my computer.

I have no problems with making competent backups from Cpanel.

willhowlett’s picture

You might want to consider consolidating your sites into a multisite install, that way you only have to replace the core drupal files once. You still have to take all the sites offline and run update.php individually though - which means letting all your clients know that their sites will be offline at the same time, but it makes it easier and quicker. I agree it would be fantastic if you were able to update them all at once.

VM’s picture

read the 100's of posts already on the forum describing the same technique. What you are reading is the upgrade.txt in the release and that document plays it extremely safe.

I don't mean disrespect... but I don't know who you are or if you know what you are talking about.

That holds true for most everyone who responds to you on a support forum. If you have someone specific you would prefer to ask. Do so using private messages.

Sorry, but someone needs to make an officious declaration about what you said. I would absolutely LOVE to do what you say.

You can offically test the technique on a test site rather than question the integrity, with or without disrespect, of people supporting you on the forums. ; )
Aftetrall you should have a backup of the files and such, or you can reobtain them from project/drupal and use one of the database backups you've already made for 6.14. After the upgrade on a test site, diff the database's ; )

domineaux’s picture

read the 100's of posts already on the forum describing the same technique. What you are reading is the upgrade.txt in the release. which plays it very safe.

I have a document that indicates how do to the upgrade, and I have thousands of hours of work in the 19 site I have to maintain and upgrade.

That holds true for most everyone on a support forum

Sorry, but someone needs to make an officious declaration about what you said. I would absolutely LOVE to do what you say.

test the technique on a test site rather than question someone's integrity.

What would be wrong with Drupal devs amending the upgrade.txt documents to indicate what you are saying.

After programming for years one thing we learn to do is follow documents to the letter or pay the consequences.

Testing techniques is fine, but why should anyone have to do that.

Drupal is a mature application, thousands use it and will be upgrading within the next few days.

I'm not trying to be difficult. I will give it a go, as VM suggested on one of the smaller sites.

I think I made my point, and for darn sure I'm not ragging on anyone.

I appreciate all the responses.

VM’s picture

What would be wrong with Drupal devs amending the upgrade.txt documents to indicate what you are saying

because the upgrade.txt is playing it safe, as it should, IMHO. Shortcuts can be designed by the admins themselves.

I break it down this way.

minor to minor = update
major to major = upgrade

For a moment think about why this best practice is in place to begin with. Major to Major upgrades, like 5.x to 6.x for example. The theme and modules you were using for 5.x sites won't work on 6.x sites. Thus they get disabled. Drupal doesn't make API changes in minor updates, only bug fixes and security vulnerabilities get in. Thus minor to minor updates typically don't break anything. However, a full reading of the release node for every upgrade/update , including minor to minors, should be read and changes that went in should be investigated to ensure a smooth upgrade/update.

lastly if you want to upgrade.txt file altered, file an issue and suggest the verbiage. That's how things get amended in drupal land.

domineaux’s picture

I think I have said about all that needs saying.

Again, thanks for your response.

VM’s picture

Congratulations for saying all you've needed to say however, you've done little beyond complain and make a suggestion in the forums which isn't the proper protocol if you want change in a core file.

Thanks though for being a contributor, the community at large appreciates the effort ; )

domineaux’s picture

Found a bug...

The forums wouldn't allow access to edit my last post, and obviously I'm logged in or I couldn't write this.

Do I have to remove all of the previous version of Drupal from the webserver, and upload the entire new version.

Or can I just overwrite the previous version on the webserver.

VM’s picture

no bug, you can't edit a comment that has been replied to.

Sometimes I overwrite sometimes I delete the old files first. Take care with .htaccess as this will need to be replaced or the changes that went into the file will need to be made into your .htaccess on the production site.

domineaux’s picture

Thank you VM

cantthinkofanickname’s picture

I did not do 4 or 5 as I posted in the other recent post this forum. Nothing is rally going to happen is it? It's only a DB operation. It owuld be nice to know exactly what the update script does. Anyone?

Sam308’s picture

Try this Drupal 6.x Upgrade method, it is easy, fast, and works well:

Drupal 6.x Upgrade - Files Only