4

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
  • What is the exact version of this Drupal 7 site? Is it already 7.36, or is it some earlier version? – Pierre.Vriens May 4 '15 at 18:48
  • It's 7.33 on both live and development. I checked the release notes for newer versions in response to your comment and didn't see anything about registry or weight unfortunately. – sa289 May 6 '15 at 0:00
0
+50

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.

| improve this answer | |
  • Will using that module help determine what happened? We want to make sure it won't happen unexpectedly in the future. – sa289 Apr 30 '15 at 16:56
  • Refer to my edited answer (last parg I just added) – Pierre.Vriens Apr 30 '15 at 20:34
  • I awarded the bounty to you and will plan to report back if we find anything conclusive. – sa289 May 6 '15 at 5:57
  • Merci beaucoup (Thank you!). Know that I am still investigating a few other possibilities (after you confirmed 7.33 as version). I also plan further enhancing my answer ... And also may question how you came to the weight as causing the problem (I think there is something ELSE that caused it). At least if you are OK in me doing so. FYI : receiving bounties is 'nice', but not 'the' reason for me to answer questions, and continue enhancing them, understand? PS: why not enhance your profile to at least include your first name? – Pierre.Vriens May 6 '15 at 6:04
  • we suspected the weight due to the nature of the error (i.e. a function that does in fact exist would in theory only be not defined if it hadn't been included yet and weight is one thing that affects the include order). When comparing the dev and live sites, the weight values were different and changing the weight on the live site to match the dev site resolved the issue. What's your other theory as to the cause? – sa289 May 19 '15 at 23:39
0

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.

| improve this answer | |
  • Do you have any ideas on what may have caused this? We want to make sure it won't happen unexpectedly in the future. – sa289 Apr 30 '15 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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