Recently I was updating a website for a client for security upgrades to modules and adding some new functionality to the website. 1 update I was running was upgrading the Webform module from 3.x to version 4.x. Upon finishing up the upgrade I noticed I was receiving some odd errors as if I had not upgraded the module. Upon inspection I discovered I had 2 instances of the module installed and the Drush pm-info command was crucial in discovering this oversight.
The primary issue with the site in question is that in Drupal a module may be installed in many locations. An overview of those locations can be seen in this writeup I provided on Drupal.Stackexchange — I am aware of this functionality of Drupal. But, my site was still experiencing odd issues with the update, so I thought maybe this detail was playing a part in my website.
I develop my websites lately as an Install Profile, so my modules typically live in /profiles/MYPROFILES/modules. Often times though if I’m performing an emergency fix or add-on to a website I will place new modules in /sites/all/modules as modules in this location will be seen by all sites powered by the Drupal installation regardless of their Installation Profile.
I wanted to inspect what version of Webform my website was running after the upgrade and I issued drush pm-info webform:
dgurba@webserver:/www$ drush pm-info webform Extension : webform Project : webform Type : module Title : Webform Description : Enables the creation of forms and questionnaires. Version : 7.x-3.0-rc5+17-dev Package : Webform Core : 7.x PHP : 5.3 Status : enabled Path : sites/all/modules Schema : 7315 version Files : includes/exporters/webform_exporter_delimited.inc, includes/exporters/webform_exporter_excel_delimited.inc, includes/exporters/webform_exporter_excel_xlsx.inc, includes/exporters/webform_exporter.inc, views/webform_handler_field_form_body.inc, views/webform_handler_field_is_draft.inc, views/webform_handler_field_node_link_edit.inc, views/webform_handler_field_node_link_results.inc, views/webform_handler_field_submission_count.inc, views/webform_handler_field_submission_data.inc, views/webform_handler_field_submission_link.inc, views/webform_handler_field_webform_status.inc, views/webform_handler_filter_is_draft.inc, views/webform_handler_filter_submission_data.inc, views/webform_handler_filter_webform_status.inc, views/webform_plugin_row_submission_view.inc, views/webform_handler_relationship_submission_data.inc, views/webform.views.inc, tests/components.test, tests/conditionals.test, tests/permissions.test, tests/submission.test, tests/webform.test Requires : ctools, views Required by : eap_alumni, eap_base, eap_feedback_courses, eap_feedback_banking, eap_feedback_communication, eap_feedback_culture, eap_feedback_food, eap_feedback_host_city, eap_feedback_host_university, eap_feedback_housing, eap_feedback_instructor, eap_feedback_language, eap_feedback_traveling, eap_photo_contest, eap_student_feedback2, eap_student_videos, student_story, eap_student_views, student_blogs, webform_entity, webform_entity_pages, webform_validation
Drush informed me that the site believed I was running webform 3.x still because there were 2 copies of the module: 1 in the installation profile and another in the sites/all/modules folder. I guess at runtime the /sites/all/modules copy of Webform was winning as the module the site was using.
The fix to this issue was relatively simple:
- Assure that the database updates for webform were current for the 4.x version.
- Delete the erroneous sites/all/modules webform folder and contents
- Then assure the webform 4.x module is seen by the site using drush pm-info again. If not run Registry Rebuild or update the entries in the System table for the webform module file locations.