Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We get to the following error when trying to update to 7.x.1.1:
Update #7007
Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 3 [:db_insert_placeholder_1] => moderate content from published to draft [:db_insert_placeholder_2] => ) in user_role_grant_permissions() (line 3028 of /[PATH]/modules/user/user.module).
Comment | File | Size | Author |
---|---|---|---|
#15 | workbench_moderation_1330304+Update+error+7007+if+module+is+disabled+while+upgrading.patch | 954 bytes | hass |
Comments
Comment #1
Jean Gionet CreditAttribution: Jean Gionet commentedexact same issue here
Comment #2
stevectorWhat version of Workbench Moderation did you upgrade from?
Comment #3
travelerttSame here, Updated from version 7.x-1.0.
Comment #4
akosh CreditAttribution: akosh commentedIt was the last stable, 7.x-1.0.
Comment #5
stevectorDoes this error occur repeatedly? Try clearing caches and running the update again. On client projects I've occasionally needed to build cache clears into update functions involving permissions. That might be needed in 7007 too.
Also, please change the status back to active when responding.
Comment #6
travelerttIt does occur repeatedly. I just tried clearing the cache then running the update again, same error.
Comment #7
jaiiali CreditAttribution: jaiiali commentedsubscribing
Comment #8
stevectorI was able to reproduce this. Working on a fix.
Comment #9
stevectorMy reproduction of the error turned out to be a bug in the install profile I was using.
Can you give me a list of the states and transitions configured on your site?
Comment #10
travelertt@jaza_sa You don't need to do that anymore, just click the "Follow" button, to subscribe to the thread.
Comment #11
stevectorThis hasn't been updated in four weeks. Please reopen if there are specific instructions to reproduce.
Comment #12
longwaveI am also seeing this. I don't have further time to test right now but Workbench Moderation is currently disabled and I think this may be the cause.
Quickly tracing through the code suggests that calling user_role_change_permissions() from hook_update_N() will only work if the module that owns the permission is enabled during the update, as it eventually calls module_invoke_all('permission') to look for the module that owns the permission, but if the module is disabled this will be NULL.
Like many functions that eventually call module_invoke_all() I guess this means it is unsafe to call user_role_change_permissions() from hook_update_N() and you should modify the database directly in this case.
Comment #13
longwaveOK, so in fact I did have time to test quickly. I successfully updated via drush with:
I'll take the liberty to downgrade this to normal as it won't affect most users of this module.
Comment #14
hass CreditAttribution: hass commentedI believe I have an idea why this happens. The workbench_moderation.module file is not loaded in .install file if the module is disabled. Therefore the workbench moderation permission from hook_permission cannot be found in user_role_change_permissions(). We only need to
require_once
the workbench_moderation.module file on top of the upgrade function and the issue should be solved. It is well known that this is required in .install files if modules are disabled.Comment #15
hass CreditAttribution: hass commentedPatch attached.