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.
Looking for quality Drupal Hosting? Look no further than Arvixe Web Hosting!
