Accidental Drupal 6 install
A client of mine recently accidentally unpacked a drupal folder (specifically, drupal 6) into the modules directory. What this means, unfortunately is that the next time drupal is asked to render the page, it looks in the modules directory, sees the new drupal folder, and thinks that the modules folder inside THAT drupal installation is the place it should look for modules. So you'll get a slew of errors, more depending on how many modules it took to render that page.
So just delete the offending drupal installation right? Sure, that's the first step. Then you're going to get a lot of 500 internal server errors. These errors drove me nuts but I finally figured out what the trouble is.
See, when drupal renders the page, it dynamically searches the modules folder. When it finds those offending modules, it's going to go back into the database and write those new paths in as the location for those modules. By deleting them you've taken care of half the problem.
So how do you fix the rest of it, and get rid of the pesky 500 errors? Easy. Just go into your database and find the "system" table. You'll see a field that stores the path for each of the modules. You should be able to see fairly quickly where the path to the modules has been changed from sites/all/modules/blah to the extra drupal directory. Change those directories back to the way they should be, refresh the cache, and you'll be good to go!
This particular occurance happened with a drupal 6 folder being put into the modules of a drupal 5 installation. That was my first clue, because the error messages were as if drupal 6 modules had been installed on our drupal 5 system. If you unpacked, say, drupal 6 into drupal 6 modules, you wouldn't lose functionality perhaps, but eventually it would come back to bite you.
If you've had any experience with this, leave a comment and add to the conversation.
A client of mine recently accidentally unpacked a drupal folder (specifically, drupal 6) into the modules directory. What this means, unfortunately is that the next time drupal is asked to render the page, it looks in the modules directory, sees the new drupal folder, and thinks that the modules folder inside THAT drupal installation is the place it should look for modules. So you'll get a slew of errors, more depending on how many modules it took to render that page.
So just delete the offending drupal installation right? Sure, that's the first step. Then you're going to get a lot of 500 internal server errors. These errors drove me nuts but I finally figured out what the trouble is.
See, when drupal renders the page, it dynamically searches the modules folder. When it finds those offending modules, it's going to go back into the database and write those new paths in as the location for those modules. By deleting them you've taken care of half the problem.
So how do you fix the rest of it, and get rid of the pesky 500 errors? Easy. Just go into your database and find the "system" table. You'll see a field that stores the path for each of the modules. You should be able to see fairly quickly where the path to the modules has been changed from sites/all/modules/blah to the extra drupal directory. Change those directories back to the way they should be, refresh the cache, and you'll be good to go!
This particular occurance happened with a drupal 6 folder being put into the modules of a drupal 5 installation. That was my first clue, because the error messages were as if drupal 6 modules had been installed on our drupal 5 system. If you unpacked, say, drupal 6 into drupal 6 modules, you wouldn't lose functionality perhaps, but eventually it would come back to bite you.
If you've had any experience with this, leave a comment and add to the conversation.