Drupal is quite involved and reading manuals is hard for some people. So they put non-core modules into the modules folder. They hack core files. They hack modules. They hack themes. And worst of all: They are unable to document their whatever-you-wanna-call-it. A customer came back to us to update his Drupal 7 site. The people who created the website were not available - guess why. So here is what we did.
Set Up Update Workflow
We had to re-start the whole update process many times, because we broke the installation often. So we documented every single step in a step-to-step document. We used a drush dump from the live site and deployed it on a test hosting.
Move Modules to Correct Place
In our case, there were non-core modules in the core modules folder. Some modules were present twice, once in the modules folder and once in sites/all/modules. Both of them in different versions of course. Drush cannot handle that mess. It assumes every non-core module in the sites folder and overwrites updated modules there. On updating a site, this behavior leads to duplicate modules. Furthermore, a core update breaks everything, because drush overwrites the core modules folder so many modules are missing afterwards.
We downloaded Drupal to compile a list of standard core modules. We compared the list against the list of modules present in our core modules folder and built the complement. We deactivated all modules in that list, moved the modules over to the correct folder and re-enabled them. We found that some of the modules were duplicates. We looked at the activated versions and only copied the modules over that were really enabled. We deleted remaining folders and enabled all modules again.
drush dis -y NON-CORE-MODULES-IN-CORE-FOLDER rm DUPLICATE-MODULES mv NON-CORE-MODULES-IN-CORE-FOLDER sites/all/modules drush en -y NON-CORE-MODULES-IN-CORE-FOLDER
Get drush up Working
drush up gave us a headache on this site. The most problematic things were:
- Duplicate project keys. This site uses the community theme and the dropletz_helper_tags module. We removed the project = "omega" and roject = "shortcode" from their respective info file to be able to proceed with drush up.
- The error "The MODULE-NAME directory could not be found within the modules directory at..." regularly occured. It was usually connected to duplicate modules of which the duplicate was removed from the core modules folder like described above. Disabling and re-enabling the module and Cache-Clears helped sometimes. Maybe drush up just wants to be called more than once.
- Remove symbolic links from the drush archive-dump target folder. Otherwise it fails.
Handle Hacked Modules
After a successful drush up we tested the site with the customer. There was one error causing a 500. It was connected to a code error in a media module. We found that at least one of its dependencies was updated so that a function was missing there. We compared the module to its original and found that there are too many changes. We decided to keep it and all its dependencies at the old version. Thus, we added a step to our update document that disables these modules, moves the folders away from the Drupal root and moves and re-activates them after the update.
For every graphical deviation from the live site, we looked at deviating CSS and HTML. We found several hacked modules and re-applied the hacks to the updated modules. We documented them so that we can get rid of them soon or are at least able to re-apply them after the next update.
Test, Test, Test
We found that the .htaccess file was changed and overriden by the core update. So we included it in our update list. Our list also contains the change of the memcache key, since it causes problems when running another site on the same server using the same key.