0
votes

I accidentally installed a drupal update (6.26) into sites/all/modules (yes, I put there the whole drupal root directory, so I have sites/all/modules/modules, sites/all/modules/sites/all/modules, etc).

Then, unknowingly ran update.php, and everything went ok as Drupal intelligently registered the new core modules in sites/all/modules/modules/* as core modules.

This worked fine until the next update. I placed the core drupal files into the root dir, and the core was correctly replaced with 6.27. But in sites/all/modules were the 6.26 files from the last update and drupal accepts OLDER files in sites/all/modules that override the core /modules files.

So drupal now complained that it was still at 6.26, even when the real core was at 6.27 - those files were never actually called, because overridden by /sites/all/modules/modules/*.

So: I managed to remove all the unneeded modules from there and with a few errors, I got it working again. the best method was: changing the sites/all/modules/modules/<module>/<module>.info file and tweaking the version number from 6.27 to something older, like 6.25. THEN run update.php - so Drupal recognizes that there is an OLDER version in sites/all/modules than in core. now remove the directory and run update.php again. Now everything is clean for this module.

But this does not work for the system module. Each time I try to remove the sites/all/modules/modules/system/ directory, the update.php URL is not callable any more (HTTP Error 500).

Any hints how to recover from an accidentally overridden system module?

1
Do you have a backup before the update? And don't complicate your life with such a nested folder structure. - Max
ah, no backup (shame on me.) - Complicated folder structure? It's the original drupal structure... The only change was the accidentally "root update" into the /sites/all/modules dir, so I had accidentally a whole drupal subsystem in /sites/all/modules. - nerdoc
yeah, I was referring about the a full drupal under sites/all/modules directory. what happens if you remove that and basically have a, among friends, a normal version? - Max
It looks like your {system} table is broken. Can you run this query and paste the result: SELECT filename FROM {system} WHERE name = 'system'? If the path is not something like this: modules/system/system.module then at least we know where the problem is. - Max
Yes it does, it seems that your {system}' table is broken. You're missing at least 2 important lines: modules/system/system.module` and modules/user/user.module. Do you have Drush installed? - Max

1 Answers

0
votes

I finally found the answer (Thanks to Max), and want to share it in case of other people suffer from the same problem.

This solution should work if you accidentally installed a drupal update into a subdirectory like /sites/all/modules. After running update.php, the system db table gets updated to the new paths, so all modules that are not in /modules have priority over the ones in /modules. You can deinstall all optional modules, so that they get purged from the system table as well with no problem.

In case of the system module, this is not simply possible, as you cannot deinstall the system module, when a wrong one is installed.

So what you have to do is:

  1. Open the system table with e.g. phpMyAdmin, and search for the system module: SELECT * FROM system WHERE name = "system".
  2. change the filename field from "sites/all/modules/modules/system/system.module" (or whatever there is) into "modules/system/system.module"
  3. Now (and this is important before you run update.php!) delete the wrong system module folder.
  4. Run update.php

Now Drupal should find the original (built in) system module - everything should be ok.