Some modules have deïnstallation routines. Which typically remove databasetables for that module, variables from the variable table and locales introduced by that module. These routines live in the
.install of that module.
Therefore, they cannot be ran without that module being present. So here are our current steps. My question is: can this be done simpler and more effectively? Say I remove foo_bar module.
- In the RCS, prepare a new release, where:
- All css and theme-overrides that use or build on top of- foo_bar are removed.
- All css and theme-overrides for modules depending on foo_bar are removed.
- Push that release to acceptance. Test the deïnstallation (from admin/modules) with a very recent copy of the production database.
- If all goes well, deploy the new codebase to production, and deïnstall foo_bar and its dependencies there. This will invoke the uninstall in the various modules, cleaning up the database.
- In the RCS (git), prepare a new release where the code is actually removed.
- Deploy that to acceptance where we test if nothing accidentally depended on this (some ugly modules or theme functions include files directly from other modules. Most notably CSS, JS or image-files).
- If accepted, deploy new release to production. production now has a clean database and a clean codebase.
Problem that I can't see how to solve, is that this always needs two releases. Since in Drupal a release requires the site to be offline, this means two times downtime just to remove one module. It also requires two release procedures, which, in professional hosting environments can be very expensive, time-consuming or frustrating.
If we remove the module from codebase in the first iteration, we cannot run the uninstall hooks, keeping many lint in the database; not just a few tables, but mostly variables and locales. If we don't remove the module from codebase, that means the codebase will grow with stale, unused code; this gives no performance overhead, but does make maintaining the code harder and harder.
How do you deal with this?
[edit: added note about deployment being a tough procedure, often]