By Sturmey on
I see a lot of posts about the troubles that people have had trying to do the upgrade to 6.16.
I had a complete crash of my installation when I tried to upgrade, and I've seen many other issues from small to big related to this upgrade.
After browsing through this site I found the usage statistics and realized that there are many people who don't even bother with upgrading their sites which makes sense if they want to avoid some of the issues in this forum.
So after trying to upgrade and totally crashing my site I reverted to the previous installation and started searching for an answer to this question; Is there a way to do the upgrade that guarantees it will succeed?
Don't say follow the instructions in upgrade.txt, I tried that already.
Comments
=-=
Yep, I successfully upgraded 6 sites.
I don't take the steps of disabling modules and switching themes for a minor upgrade.
I simply; I put the site in offline mode, backup my sites database, back up all files and folders.
Then I delete all files and folders except for the sites folder (this should be holding all your uploaded files. themes. and modules that are custom or contrib. if not adjust accordingly)
upload the updated files and folders except for the sites folder
I compare and if necessary merge any customizations or changes in the new with the backed up robots.txt, default.settings.php (and settings.php if required), and .htaccess
run update.php
clear cache tables
put drupal back online
test
I always do so on a test site that mimics my production install first to ensure that my production site doesn't stay down unnecessairily.
Clear cache tables?
What do you mean by "clear cache tables"? Is this your browser cache or your drupal db cache? How did you clear the cache table?
and this "upgrade" didn't
and this "upgrade" didn't break all your menus and links? or customizations?
=-=
cache tables are in the database. there are a few. I empty them manually, some use modules like devel or admin menu to do so.
Links and everything else is in perfect working order.
I agree about the ambiguous
I agree about the ambiguous upgrade instructions and I've seen similarly confusing ones on other sites. You could end up with an old version of settings.php which may not be a problem anyway, but let's get it right.
I have just done my localhost copy:
1. Make sure I have a copy of my DB with "add drop table", etc. set I do this with phpMyAdmin of course.
2. Logon on to my site as administrator in a browser and keep that open and to one side for the moment. good to confirm what upgrade is required.
3. Copy the complete public_html (so before doing the update script I can if needed swap the old site back) to a new backup folder (siteOld).
4. Delete ALL files in the public_html.
5. Copy the new Drupal version complete to public_html.
6. Delete the default.settings.php in my backup (but maybe keep it handy in case). Note 6.16 has a slight difference in commented out features.
7. Now copy my backup "sites" folder (which of course CONTAINS the "files" folder!) and overwrite the new sites folder with it (the new default.settings.php should not change). Thus putting back all modules and the necessary settings.php.
8. Open both settings files and copy any differences in default.settings.php to settings.php BUT not any lines which are NOT commented out in settings.php e.g. your DB access lines $db_url = 'mysqli://sitename:pwd@localhost/sitename'; $db_prefix = ''; should I think remain. There may be others for yours, just be careful and think. As far as I know default.settings.php has ALL lines commented out.
9. Change the line $update_free_access = FALSE; to TRUE.
10. Go back to your browser and change the URL to /update.php and away you go.
11. Change what you did in line 9. Drupal will warn you anyway if you go back to "administration" after the update.php run.
12. Check all menus and then upgrade any modules that may be complaining>
Note I do not change to the default theme (I have one in the sites folder) but have done so previously so maybe best to bow the the more experienced advice here. I hope that's accurate, please comment and I'll edit it to correct it as necessary. NO responsibility accepted.
wow - just wow!
I can't believe how much work you go through to get your site updated. It's no wonder that the people I've talked to complain about the upgrade process.
so you wipe everything, install new, overwrite with you customizations then open your site to the possibility of someone gaining access to admin rights, then go check to see if everything is working. Hmmn, while this sounds like it might work better, I still don't see how intentionally making my site insecure for a few minutes to make it more secure later (6.15 > 6.16 is called a security upgrade) is a better idea than leaving it at a less secure version.
Basically what you're saying is that I do an in place migrate to a new installation at the new version level. Well this is what upgrade.txt is saying, I shouldn't single anyone out. It sounds to me like an upgrade module that gets the unzips the update, writes the changes, and then does the upgrade is REALLY needed. The best system I've seen is used by SugarCRM, tell it the tar.gz file and it does everything else. We need to make that happen for Drupal
=-=
For a few minutes is fine. In some cases with each day that passes after a publicly known exploit has been patched your chanes of being exploited increase. Leaving you site insecure could render your site useless depending on the exploit patched and what can be exploited by the breach.
Considering that all customization shoudl be in the form of modules and such and not hacked core files, uploading new files shouldn't be a problem. After all, settings and such are stored in the database and not in the files.
I don't make the change to TRUE in update.php. not sure why that would be needed unless one is logged out before the upgrade begins.
Using the command line speeds up the update process.