Cannot import exported Panelizer permissions using Features/defaultconfig if handler cache is stale

Might need to check in the features queue.

I think so. Marking as duplicate.

I don't think this is a duplicate.

I have other permissions.

The pdo error seems to only happen when I have "administer panelizer node" permission as part of my feature.

all the other permissions are fine.

please re-close if you do feel that it is a duplicate still.

This is a mayor problem for us. Cannot add the permissions currently through an installation profile.

I think also panelizer should have a permission for all panelized node types, which can possibly solve this for us I think.

// TB @ Wk

I have a distribution that uses tons of modules... none of them have trouble injecting the permissions on a site install. The only module that has this issue is Panelizer. I think this has something to do with how/when Panelizer is being enabled by Features. It would appear that the permissions are being set by Features before Panelizer is enabled.

There is a core patch for this problem here: http://drupal.org/node/737816#comment-6978566 -- but its purpose is to subvert the error from happening.

This is helpful, as it prevents the build from breaking. However, the permissions are not set, thus showing up in Features as overridden.

You can revert using the UI, programmatically or with drush to get the Panelizer settings enabled correctly but that is a manual step.

I tried to subvert this by enabling Panelizer first (in my case, as part of the install profile), then enable the Feature that sets the permissions after Panelizer has been fully enabled. However, this still results in the Features showing up as overridden.

I think the problem might be that the permissions are not available until after certain variables are loaded and recognized, so if the permissions are loaded before the system recognizes new functionality it won't work.

I'm actually having this same problem with Open Atrium 2 distribution. I added a patch to Features to tell me which permissions were breaking at install time, and narrowed it down to this same Panelizer issue. My permission "administer panelizer node oa_space content" and "administer panelizer node oa_space layout" saved to a feature causes the installer to fail. My Features patch will bypass this to continue the build, but as mentioned in #8, the permissions never get imported.

I will try moving these permissions into a module.install hook rather than using Features. But I can definitely verify that this is something related to how/when Panelizer is creating these permissions and is not a general problem with Features itself.

Because the number of potential permissions can be weighty, it is very true that Panelizer will not create permissions until the entity bundles in question have been panelized. Otherwise the list of permissions for Panelizer would be *super* long.

So I'm guessing that features won't import the permission if it doesn't already exist, but because the panelizer settings haven't been established yet, Features doesn't import the permissions. I don't really know a good solution to this.

A couple of possibilities:

1) We could create a special flag in maintenance mode that makes all permissions available at install time. That way features will detect the potential permission, but as soon as the site is loaded for real, it will work.
2) Features could change the order that it imports things.

#1 is probably the simplest solution, and should be a relatively easy patch. Is there anyone in this issue willing to give it a shot? It's probably only relatively easy because there's quite a lot of logic in panelizer_permissions and most of that logic will need to be set to: if (defined('MAINTENANCE_MODE') || (/* old logic */)) but I can't say for sure that every if in the function would be like that. Probably so.

I've created a patch that resolves this issue for me based on merlinofchaos's suggestion in #13. I created the patch against 7.x-3.x-dev since the issue still exists in the latest dev branch. The code looks identical to the 2.x branch so it should apply there as well, or at least be trivial to backport if necessary. Please review/test my attached patch and chime in if this resolves the error for you so we can get it committed!

I think can happen outside of site install if enabling features including the strongarmed variables that enable the permission and the permission .

The stale cache is panelizer_entity_plugin_get_handler. It needs to be cleared before features rebuild of the user_permission but after the strongarm rebuild of the variables defining it. There's no good one feature hook to clear it :/.

Once off for each effected feature is

/**
 * Implements hook_pre_features_rebuild().
 */
function <feature name>_pre_features_rebuild($component) {
  if ($component == 'user_permission') {
    drupal_static_reset('panelizer_entity_plugin_get_handler');
  }
}

I not a fan of ^ patch as it's just working around the stale cache instead of refreshing the cache and other things may go wrong due to stale cache. Also, it assumes maintenance mode is only time when will encounter this.

Changing to title to reflect it can happen outside of site install

Also setting it to needs work as won't cover other instances of the issue

Just confirming that #14 works for install profiles but doesn't cover all use cases.

Going to work on a patch to change the hook I used above (which currently only called if implemented by the module being rebuilt) to a real hook #2009174: change pre_/post_ hooks to generalized hooks, that way someone (panelizer) can implement it and clear that cache as needed

however the same issue exists with default config, which does it's own permission rebuilding #2008178: Fatal error when adding a permission that doesn't exist

Added more code for better example

Could everyone please try the patch in #2206961: Update the plugin attached to an existing handler and let me know if it resolves the problem.

Closed a duplicate: #2038559: To many conflicts when working with featurized content permissions.

@hefox: If you have the time, I'm happy to work on this over the next week from the Panelizer side to resolve this long standing problem?

Fix warnings when $settings['view modes'] is not set

The latest patch from #2206961: Update the plugin attached to an existing handler resolves this issue for me.

So this is effecting OA again, but instead of digging into the internals and trying to find the exact hook where clearing the cache would work, it's just a quick "hey, you doing a features restore/rebuild that might cause this bug? kill the annoying caches that cause this and rebuild". So only negative effect, that I can think of, is that features rebuild may be a big longer (didn't notice much) as it has to rebuild that cache.

@hefox: Am concerned at it clearing ctools_get_plugins_reset too, on a large site might that not be problematic?

Rerolled.