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.
After upgrading to 1.13 I am getting some problems on my local setup when doing drush si for my child distro.
WD php: Notice: Undefined index: delete terms in [notice]
employee_type in user_role_grant_permissions() (line
3111 of
/home/codio/workspace/modules/user/user.module).
exception 'PDOException' with message [error]
'SQLSTATE[23000]: Integrity constraint violation: 1048
Column 'module' cannot be null' in
/home/codio/workspace/includes/database/database.inc:2171
Stack trace:
#0
/home/codio/workspace/includes/database/database.inc(2171):
PDOStatement->execute(Array)
#1
/home/codio/workspace/includes/database/database.inc(683):
DatabaseStatementBase->execute(Array, Array)
#2
/home/codio/workspace/includes/database/mysql/query.inc(36):
DatabaseConnection->query('INSERT INTO {ro...', Array,
Array)
It is related to defaultconfig user permissions. If I comment out all the permissions in my modules the error goes away. However, before upgrading I was able to succesfully build it all.
Comments
Comment #1
lsolesen CreditAttribution: lsolesen commentedSeems to be caused by accidentally downloading drush 7 when setting up a new box.
Comment #2
lsolesen CreditAttribution: lsolesen commentedHm, seems it is also the case using drush 6.
Comment #3
lsolesen CreditAttribution: lsolesen commentedI tried cloning the most recent defaultconfig and only applied this patch: https://www.drupal.org/files/issues/defaultconfig-rebuild-2008178-9.patch. That fixed it for me.
Though that gives me a lot of warnings afterwards with permissions not defined.
Comment #4
dsnopekIs the module that has the defaultconfig for those permissions the same module that is declaring the permissions (ie. declaring the "employee_type" taxonomy)?
This error is usually caused by Features trying to set the permissions with defaultconfig BEFORE creating the thing that defines the permission (ie. the taxonomy). In Panopoly, we've had to work around this in a couple places, for example, Panelizer permissions in panopoly_pages (see
panopoly_pages_modules_enabled()
).Anyway, if that is the case, the really weird thing is how it worked for you before the update! Maybe it's because of the update to Features 2.2? Can you try downgrading Features to 2.0 and seeing if that fixes
drush si
?Comment #5
lsolesen CreditAttribution: lsolesen commentedemployee_type taxonomy is in the same module. Downgrading to features 2.0 does not seem to solve the issue. Also it does not seem to be reproduced on my tests?
https://travis-ci.org/vih/vih-build/jobs/39525956#L614
Comment #6
dsnopekOk, in this case, I think you need to do the same thing that panopoly_pages is doing for Panelizer permissions: setting those permissions in
hook_modules_enabled()
. I don't know any other solution to this problem, otherwise I would have used it in panopoly_pages. ;-)See
panopoly_pages_modules_enabled()
for an example of how to do this:http://cgit.drupalcode.org/panopoly_pages/tree/panopoly_pages.module
Comment #7
dsnopekThis sounds suspiciously like this issue which has a patch: #2183937: Error on install of Panopoly-based install profile: "Column 'module' cannot be null" when profile starts with "e"
Can you try with the latest Panopoly and that patch and let us know if this is still happening? Thanks!
EDIT: Sorry, it's not fixed yet, but it has a patch.
Comment #8
dsnopekNo response for a long time! Closing for now, but feel free to re-open if you add them.