0

As a long time Drupal dev, I should probably know the answer to this question, but I'm stumped by the behavior I'm seeing.

Let's say I have a local and a remote site. On the remote site a module is uninstalled properly and the module code is removed from the file system (git tracks the deletion, etc).

Then to get my local installation up to date, I completely drop all tables in my database (it's completely empty) and I do a git pull, so the local module files are deleted. I then get the remote database and load it into my local.

In that situation there are no database remnants from my old local install and the file system is updated with the deleted modules. It should reflect the remote site completely.

However, when I load up the local site I get all the 'XXXX module is missing" and everything breaks. I run the registry rebuild via drush rr, and it fixes everything. But then, going forward into the future, I continue to see this broken registry each time I reload the site from the remote database (meaning I have to rr each time).

This strikes me as so odd...because where are those old registry records stored outside the database? Why, if I have a fully clean database, does it recognize old modules as missing?

And of course...how can I 'clean them up' permenantly?

Improve this question
3
  • 2
    You’re not copying the cache table data down are you? If so, script something to stop that happening, it stands to reason there could be invalid path references in there from one environment to another. If you’re not, check any non-DB cache you have enabled (redis/memcache/etc) has been cleared properly on your local machine
    – Clive ♦
    Commented Apr 26, 2018 at 13:15
  • I want copying any cache files when moving the database...as you mention, and as mentioned below, it must be an external cache retaining the 'bad' module data.
    – Feature
    Commented Apr 27, 2018 at 12:14
  • How aggressive is your op code caching?
    – Frank Robert Anderson
    Commented Apr 27, 2018 at 16:45

1 Answer 1

Reset to default
1

Common causes:

  • External cache (Memcache, etc) that is not purged on rebuild
  • Your SQL import contains cache from prod (I tend to make sure backups make cache tables structure-only).
  • Your SQL is imported into a DB which contains tables, but does not drop some of them (such as cache). (I personally drop and create the DB before each import).
  • The module is still enabled/present in the system table (confirm in your SQL that the row in the system table is gone/disabled & uninstalled).
  • Something else on your site depends on it and is re-enabling it (eg master module, feature dependencies, etc (although dependencies usually block things from being disabled)).
  • Sometimes worth doing a drush cc drush after importing the SQL. When in doubt, clear caches ;)
Improve this answer
1
  • Nice, thanks...I think in my case it was an external cache that wasn't fully cleared (because nothing else really makes sense). I kinda suspected that must be where it was, but wanted confirmation. Thanks!
    – Feature
    Commented Apr 27, 2018 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.