Unexplained change in module weight in registry table caused site error

Question

EDIT: August 6, 2015

It turns out that this was actually caused by incomplete data of module_implements cached in the database by Drupal which caused a hook_init to not be called. We changed the weight but also had cleared the cache and had incorrectly attributed the fix to correcting the weight.

---

We have a Drupal 7 site with mimemail and htmlmail modules installed. The htmlmail has a weight of 10 since it needs to be loaded after mimemail.

However, recently, the following PHP error started occur in the logs:

PHP Fatal error: Call to undefined function mailsystem_html_to_text() in /path/to/sitefolder/sites/all/modules/htmlmail/htmlmail.mail.inc on line 62".

We were able to track it down to the "weight" column in the registry table where the weight for class "HTMLMailSystem" has a weight of 0 when it should have been 10. Manually changing it to back to 10 fixed the issue.

We confirmed that there has been no active development or any core/module updates around the site this error started to occur.

Does anyone know what could have caused the weight to change?

Futher investigation by running the following query revealed no discrepancies in module weight between the registry and system tables on the development site

SELECT r.*,
s.name,
s.weight
FROM `registry` r
LEFT JOIN `system` s ON r.module = s.name
WHERE r.weight != s.weight

However, on the production site, the following entries module entries have a different weight between the two tables so it's possible other modules were affected too by whatever caused this - it just hasn't caused additional errors (such as due to the default load order perhaps being fine for those).

views_plugin_localization_core
views_plugin_localization_none
views_plugin_row_user_view
WebformComponentsTestCase
WebformGeneralTestCase
WebformPermissionsTestCase
WebformSubmissionTestCase
WebformTestCase
webform_exporter
webform_exporter_delimited
webform_exporter_excel
webform_handler_field_form_body
webform_handler_field_is_draft
webform_handler_field_node_link_edit
webform_handler_field_node_link_results
webform_handler_field_submission_link
webform_handler_field_webform_status
webform_handler_filter_is_draft
webform_handler_filter_webform_status

Answer 1

Maybe it could help to find the answer to your question if you'd use contributed module "Registry Rebuild". That module integrates with Drush via the Drush RR command. It will then rebuild the system table.

DrupalEasy Podcast #133 further explains how this module / drush cmd can be used.

Like I wrote above, it "could" help, not sure if it "Will". The way I'd actually do it is to first clone the entire site (code and DB) in a local dev environment, then run Registry Rebuild (in the local dev site), and then compare the content of the local dev DB result with the operational site, at least for tables such as the System table. So it's like using this module to get advice (hints) on what might be the problem.

Another related thought: if the version of this Drupal site is below 7.32, then the answer to this question might simply be that your site was hacked. For way more details about that, and possible approaches to do more research on that, refer to Drupal SA-CORE-2014-005 - How to tell if my server / sites were compromised?, which also suggests to use the Drupalgeddon module.

To take this a step further (for a site with version below 7.32), look at the "accepted" answer in What kind of attacks does the patch for SA-CORE-2014-005 (Drupal 7.32) prevent? ... It should be obvious that an appropriate UPDATE SQL statement (i.e. for module "weight" in the registry table) could be the explanation of this mystery.

Answer 2

An easy way to solve this problem is to set the status of that module to 0 in the system table. Then try to uninstall them completely and then try to install and set them again.

I know this is not the best way (there are other ways), but sometimes short and not optimal method is better that spend more time on debugging.