Quoting David Christensen dpchrist@holgerdanske.com:
Earnie Boyd wrote:
What steps did you did b4 the update.php?
Thank you for replying. :-)
The short answer is, "I follow UPGRADE.txt as best I can".
Unfortunately, step 6 is vague:
Remove all old files and directories from the Drupal installation directory.
I satisfy that by never overwriting the older package with the new; I always setup a fresh new directory but copy the settings.php files I need from old to new. Run update.php only on the Drupal core first. Add the modules I need and execute update.php for the modules. This method will always deactivate any modules since they do not exist for the first update; Drupal core is smart enough to deactivate them for you.
I've never been certain as to which files and directories to remove. So when I've tried to follow the procedure to the letter, I've had to guess. :-O
I've run into issues both when attempting to upgrade/ update (broken site, locked out, operator error, etc.) and also when recovering from a failed upgrade/ update (notably restoring database images taken when Drupal was in offline mode). So, I've made adjustments to the procedure both to improve my chances of success and to simplify recovery should I fail:
- Steps 1, 2, 3, and 14 -- I login with user ID 1 (step 2), take the
site off-line by adding the following lines to .htaccess (instead of step 3):
Order Allow,Deny Allow from 127.0.0.1/255.0.0.0 Allow from w.x.y.z/255.255.255.255take backup/ archive images (files and database) (step 1), upgrade/ update per steps 4-13, take another set of backup/ archive images, and put the site online by commenting out the above lines (instead of step 14).
- Steps 6 and 7 -- my Apache DocumentRoot is a symbolic link which
points to my current Drupal installation directory. Rather than hacking up my old Drupal installation directory, I unpack the Drupal 6.13 tarball into a new Drupal installation directory, add the above lines to .htaccess, and change the symbolic link.
I use symlinks as well. My directory structure is /opt/drupal/drupal5/drupal-5.1, /opt/drupal/drupal6/drupal-6.1, etc. I also move the first instance of the sites directory to /opt/drupal/drupal[56] and symlink the sites directory, e.g. ln -s /opt/drupal/drupal6/sites /opt/drupal/drupal6/drupal-6.1/sites. This way upgrading each release of drupal6 becomes easier.
The difference here is that I don't modify .htaccess as you have. But that could be a requirement of your environment.
The modified procedure seems to have worked for minor revision upgrades/ updates (e.g. 5.x -> 5.19).
I only recently read about uninstalling Drupal modules via the UI. In the past, I thought I had "uninstalled" several modules by disabling them via Administer -> Site Building -> Modules -> List and deleting their files. So, there may be (database?) leftovers from past modules that are causing problems now. I don't know how to check for this condition. I assume the fix would be to install the modules again and uninstall them properly (?).
Well I would make sure to follow each modules instructions. Certainly deleting files that have been uploaded or needed for the site to work isn't desirable. I remember that I had an issue the first time I tried to update from 5 to 6. But then I decided to, first upgrade to the latest 5.x version. Upgrade to version 6 without contrib modules installed. Then install contrib modules and upgrade. These actions produced a working application. I don't remember if I noticed any errors from the update.php but it seems maybe there were some for a few modules.
You need to upgrade to the latest version of 5.x because the updates are not carried from version 5 to version 6. Perhaps that is the step you need to take.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/