Travis reported the following to me:

Starting Drupal installation. This takes a few seconds ... [ok]
WD php: PDOException: SQLSTATE[23000]: Integrity constraint [error]
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] => administer panelizer taxonomy_term
panopoly_categories breadcrumbs
[:db_insert_placeholder_2] =>
in user_role_grant_permissions() (line 3054 of


populist’s picture

Assigned: Unassigned » populist

I know I know..... here is the trouble:

part of RC3 is adding permissions for the editor/administrator roles so that we have a cleaner out of the box experience for non-root users
which means we define permissions in defaultconfig with logic like:

// Exported permission: administer panelizer taxonomy_term panopoly_categories breadcrumbs.
$permissions['administer panelizer taxonomy_term panopoly_categories breadcrumbs'] = array(
  'name' => 'administer panelizer taxonomy_term panopoly_categories breadcrumbs',
  'roles' => array(
     'administrator' => 'administrator',
   'module' => 'panelizer',

the problem is that features/defaultconfig use standard drupal user_permissions_grant operations to add the permissions as part of their installation
which currently is erroring out with this error:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission}

i traced it back and the problem is that when the user permission is being assigned, drupal doesn't know that a permnission set like "administer panelizer taxonomy_term panopoly_categories breadcrumbs" actually exists! which is because panelizer_permission() doesn't properly set them up during the installation process which is wierd because it should:

foreach (panelizer_get_plugins_with_hook('permission') as $handler) {

the problem is that $handler->hook_permission($items) doens't return anything because the "bundles" are not being properly set on the Panelizer entities which i believe is a caching issue with ctools_get_plugins('panelizer', 'entity')

populist’s picture

Title: Newest Dev Breaks Drupal Installer » Troubles Implementing Default Permissions for Panelizer
Status: Active » Needs work

I am going to break this out into its own issue since it is pretty complicated. After more digging in the analysis from #1, the trouble is that $handler->hook_permission($items) doesn't return anything because the "bundles" are not set since the *taxonomy* isn't actually enabled until later (despite the panelizer settings being set up) and it requires a features_flush_caches() to work correctly which isn't cleanly going to be able to be injectable.

In a nutshell, our problem when we want to (a) set up an entity type (i.e. taxonomy vocabulary), (b) set up a panelized version (i.e. panelizer default), and (c) add permissions as per:

features[defaultconfig][] = panelizer_default:taxonomy_term:panopoly_categories:default
features[defaultconfig][] = panelizer_default:taxonomy_term:panopoly_categories:default:default
features[defaultconfig][] = panelizer_default:taxonomy_term:panopoly_categories:default:featured
features[defaultconfig][] = user_default_permissions:administer panelizer taxonomy_term panopoly_categories content
features[defaultconfig][] = user_default_permissions:administer panelizer taxonomy_term panopoly_categories layout
features[taxonomy][] = panopoly_categories

The trouble, in load order, is:

defaultconfig_modules_installed() fires when the module gets turned on and installs the panelizer_default options
defaultconfig_modules_installed() then continues to install the user_default_permissions which ERRORS as per the situation in #1
features_modules_enabled() never gets run to setup the taxonomy.

The fix, interestingly enough, is to make sure that features_flush_caches() is run in the process but that just executes the features_rebuild() to install the taxonomy ahead of time.

sylus’s picture

Thanks so much for the detailed write up and helping me understand the problem.

I completely understand the reason behind using default config. Really amazing the level of thought you have put into panopoly to make it extendable. ^_^

sylus’s picture

Hey so if I read the workaround, after I would for example say install panopoly I would manually call features_flush_caches from my install profile?

Trying to put a fix in place so other people won't run into this problem ^_^

populist’s picture

I implemented a work around in RC3 that avoids this problem. The tentative solution is to install permissions as part of hook_modules_enabled post installation as per panopoly_core_modules_enabled(). This will need cleanup, but it works for now.

populist’s picture

Status: Needs work » Closed (works as designed)

I am going to close this issue since things are working, but there will likely be some followup issues once we clean this up.

helmo’s picture

Status: Closed (works as designed) » Active
19.42 KB

Sorry to open this up again, but I think there is indeed some followup needed.

I just tried to install panopoly using drush and aegir, which failed with the same error as in #0

Both 7.x-1.0-rc3 and the latest git dev version had the same effect.
I'm attaching a debug log of the drush site-install command.

omega8cc’s picture

Note that Panopoly 7.x-1.0-rc3 works just fine with BOA, but we are using Aegir 2.x with Drush 4.6-dev. Not sure if this could make any difference.

barraponto’s picture

I've got the same issue when trying to add default permissions (or defaultconfig permissions) to features. While I managed to get it working by copying over the Panopoly fix mentioned by @populist in #6, the best workaround consists of adding panopoly_core as a dependency in your feature, so it is installed first.

Maybe we should add that to Panopoly App developers guides/documentations.

barraponto’s picture

@populist, regarding the workaround introduced in 0b15fffe, shouldn't panopoly_core_modules_enabled implement hook_enabled instead? As it is right now, it will perform the check every time a module is enabled.

populist’s picture

Status: Active » Postponed

@barraponto - quite possibly. this needs a deeper dive with the latest version of features + panelizer. the workaround in panopoly_core is not ideal, but postponing till post RC4.

barraponto’s picture

also, I think we can change:

// Only run this logic if we are executing as part of an install profile
if (variable_get('install_task', 'done') != 'done') {                                               

let's use drupal_installation_attempted instead:

// Only run this logic if we are executing as part of an install profile
if (!drupal_installation_attempted()) {                                               
kevster’s picture

Ive just run in to the same issue - Im not understanding the #4 fix, sorry Im not particularly technical but Im sure other people will be having the same issue, Ive just done a standard install by downloading the whole package and running the profile install on a local WAMP setup with plenty of memory allocated an long timeouts etc.

Can someone please explain to me how I can fix this issue to a relatively non-techie person?

Many thanks..

populist’s picture

Status: Postponed » Postponed (maintainer needs more info)

@kevster - are you running into this issue when trying to install Panopoly RC4 for the first time? the issue here is related to adding custom permissions to custom panelizer defaults which is a problem for module developers, but if you are not writing complex extension code you wont run into it.

if you are running into this issue, are you sure its the same thing? sending me the error message can help figure it out since somethings the SQL errors can be a little similar.

aboros’s picture

i think it is not the same as this issue, but i am also getting a very similar error recently (as of today) when trying to install RC4. i tried with drush make then drush site-install and also installing from the browser, both fails. i am attaching a screenshot of the error in the browser, error message from drush is the following:

You are about to DROP all tables in your 'panopoly' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a few seconds ...                                                                                                               [ok]
WD php: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module)      [error]
VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
    [:db_insert_placeholder_0] => 3
    [:db_insert_placeholder_1] => delete any files
    [:db_insert_placeholder_2] => 
 in user_role_grant_permissions() (line 3076 of /Volumes/HDD/Users/aboros/Sites/panopoly.local/modules/user/user.module).
WD php: Warning: Cannot modify header information - headers already sent by (output started at /Volumes/HDD/Users/aboros/Sites/drush/includes/ in          [warning]
drupal_send_headers() (line 1212 of /Volumes/HDD/Users/aboros/Sites/panopoly.local/includes/
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] => delete any files
    [:db_insert_placeholder_2] => 
 in user_role_grant_permissions() (line 3076 of /Volumes/HDD/Users/aboros/Sites/panopoly.local/modules/user/user.module).
Drush command terminated abnormally due to an unrecoverable error.                                                                                                       [error]

the really confusing part for me is that i installed panopoly rc4 with both drush and 'normal' way multiple times in the past week without any issues. i am first experiencing this problem today. i don't know if it makes any difference, but i follow your documentation found here: but with a little change, before running drush make, i do a git checkout 7.x-1.0-rc4 .. this worked flawlessly on monday and last friday as well, but not today :)

i hope it helps.
thank you for this awesome product, i really love it, it makes my life a lot easier.

aboros’s picture

sorry, nevermind my comment, i just figured i was doing it wrong.
however, i feel that build-panopoly.make should include a git head ref, insted of just saying:
projects[panopoly][download][branch] = 7.x-1.x

because this way drush make build-panopoly.make will always build a dev version.

but it is a totally different issue, maybe i will open one tomorrow. :)

populist’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Sounds good and awesome you are rocking the Panopoly! Hopefully we can get some new docs out soon to make this installation process even clearer.


roberto_araya’s picture

@Helmo Hi!, I have exactly the same issue, with aegir and devshop, I have disabled all Features, but still happens, only when I disabled panopoly modules it work, I'm not using panopoly distribution, it's my own install profile with panopoly modules in rc4 version.

Were you able to fix it?

mpotter’s picture

Status: Closed (works as designed) » Needs work

I am also going to re-open this issue. In researching issues in Open Atrium, I have found that this implementation of hook_modules_enabled() *is* running for EACH module enabled after it in the profile. So for Panopoly this might not have caused a lot of trouble. But in Open Atrium, we still need to install another 40 modules *after* panopoly_core.

Before panopoly_core is enabled, each module in the installer takes 5-6 seconds. After panopoly_core is enabled, each module takes 20-30 seconds. This significantly slows down the installer. Also, some people are reporting that their installation is actually hanging when it gets to panopoly_core (#2067099: Install fails after completing 135 modules).

So, as mentioned here in #10, we need to at least change this so it only runs once and not for every module enabled. Since it sounds like there are many issues with moving this work to a different area, such as defaultconfig, I'll just try some workarounds to only run this once.

Btw, #15 is a different issue related to the fact the file_entity module changed it's permission naming to have a separate permission per file type, so instead of "delete any file" it's now "delete any image file", "delete any video file"... etc. So please file that as a separate issue if you haven't already to keep this thread clean.

mpotter’s picture

Changing it from hook_modules_enabled() to just hook_enable() seems to work for me (only runs once now), but will need more extensive testing. While it helped a bit with OA2 install time, it still gets really slow after installing panopoly_core, so I'm going to dig into some debugging a bit further.

barraponto’s picture

But just post the hook_enable patch here and we can further test. It should work as expected, though.

mpotter’s picture

OK, here are two patches for converting hook_modules_enabled() to hook_enable(). The first is for panopoly_core and the second is for panopoly_pages which has the same problem.

mpotter’s picture

In researching #2067099: Install fails after completing 135 modules I have learned that it is the call to features_flush_caches() that causes the timeout. This triggers features_rebuild() which cases all features to be rebuilt. For field* features, this recreates all of the fields, which is very slow.

Seems like this is overkill for what Panopoly needs to do. We really don't need to rebuild all of the features. We just need to clear some caches so the permissions can be set. I'll try to come up with an alternative method to handle this.

mpotter’s picture

OK, ignore the patches in #22. The whole purpose of using hook_modules_enabled() was because it runs *after* the defaultconfig_modules_installed() hook, which creates the permissions in the first place.

So, rather than changing it to use hook_enable(), we need to just test to see if panopoly_core and panopoly_pages are in the list of modules being enabled.

Then, instead of calling features_flush_caches(), we just initialize the specific features that we need. For panopoly_core, we need the taxonomy. For panopoly_pages, we need the panopoly_page content type (so we revert the module itself to create it). Then we clear the 'panelizer_entity_plugin_get_handler' cache as per #1549608: Cannot import exported Panelizer permissions using Features/defaultconfig if handler cache is stale.

Here are the patches for panopoly_core and panopoly_pages. Both of these are being used in Open Atrium 2 successfully.

mpotter’s picture

Status: Needs work » Needs review
barraponto’s picture

Here's a reroll that uses drupal_installation_attempted, merges the if statements and does not add a typo to the documentation (as in #24 panopoly_pages patch above).

barraponto’s picture

mpotter’s picture

Status: Needs review » Reviewed & tested by the community

Using the above patches successfully in Open Atrium 2 now. Finally getting a successful build without any "module cant be null" errors. Verified that the correct permissions are set in the database after the install.

dshields’s picture

Is something keeping these patches from being included in Panopoly Release Candidates?

dsnopek’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc5
Issue summary: View changes
Issue tags: +sprint

Adding the "sprint" tag - we're going to focus on this for the next release!

gboudrias’s picture

Did you test with modules in sites/all ? Very hard to debug but seems to throw up the original error for me.

Edit: Disregard this, I didn't see the patch wasn't committed.

mrfelton’s picture

Status: Reviewed & tested by the community » Fixed

Fixes committed to dev. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mcrittenden’s picture

fastangel’s picture

The bug with #2183937: Error on install of Panopoly-based install profile: "Column 'module' cannot be null" when profile starts with "e" was fixed only was a problem with order enabling. No related with this patch.