Export Panelizer Configuration

Other people have had this working, and I've never actually used the features integration myself, so I'm not sure I can actually help.

I've posted a duplicate issue (now closed) #1452098: Make Panelizer settings exportable on this.

From what I can tell the Panelizer defaults are exportable but the configuration (i.e. this entitiy should be panelized, with only these layouts available etc.) is not.

I'm setting this to a feature request on the above assumption.

I'm not sure what to say; there is a hook for adding this information to the feature that is implemented. My personal experience with features on this is limited, so it's difficult for me to tell what might be wrong.

Earl - I'm sure you have more experience on this than most! Could please you expand on:

there is a hook for adding this information to the feature that is implemented

Is this suggesting that it's implemented but not working/we're not setting it up right? Should we be using an implementation of "hook_panelizer_settings()" hard coded into the feature?

Specifically, Panelizer implements panelizer_features_export_alter which is supposed to include those variables automatically with the export.

I've played around with this some more and I'm fairly certain only the Panelizer defaults can currently be exported, the settings under the 'Available Content' tab can't.

I've tried to wrap my head around panelizer_features_export_alter() but all it seems to do (that's related to this issue anyway) is to add some features variable entries into the .info file of the feature. Two of these variables, '_allowed_layouts' and 'allowed_types' seem to be the settings we're looking for however they don't include any data.

Are the settings under 'Available Content' meant to be exportable, in which case this is a bug?

They are meant to be exported along with the default, yes.

If I export separate panelizer_defaults to separate features, which are available to be applied to the same content type it seems that the code in panelizer_features_export_alter() forces strongarm to export variables that have already been exported.

Example: I have a news content type and a services content type. Each of these have their own views. I have created a feature for news and a feature for services. I also have a global feature that contains various variables, including panelizer_node:page_allowed_layouts etc. When I add my services default panelizer panel to my services feature and try to enable the feature it tells me that it conflicts with another feature.

In my mind panelizer_features_export_alter() should not exist, but if it has to then it needs to somehow check that the variables are available for export. You can't manually add the variables once they're exported, so there must be a way of checking that.

This is going to require the assistance of someone who understands how to work with features for something like this. It's entirely possible that we need to be more aggressive -- there are lots of issues with the features interaction that are just frustrating and I don't entirely know how to fix them.

It seems to me if you're going to automatically export panelizer variables you need to make sure not to export them twice. This is easily fixed by adding $variables = array_diff($variables, array_keys(strongarm_vars_load())); as per the attached patch.

I committed and pushed this and then I remembered:

Do we need to ensure strongarm is available? This might crash, unless strongarm is required for this hook to even run. Do you know?

Moving back to active; this may need a followup patch.

follow-up

Thanks! Committed and pushed!