Proper Features Support for Panelizer

Does this appear in the list when you visit Panelizer itself? If so, I have no idea why features might not be showing it.

Hmm. Features may not be able to deal with the fact that the default panel is truly a default, meaning that when its checked, Panelizer creates a default panel. I don't really know how to address that. :(

I've committed a fix that allows Panelizer to NOT show the default as a default if it detects one in the database. This should allow features to export one. However, once features has control of it, there is the potential of a collision. Need to investigate this further.

Not marking fixed yet.

How to export node-specific configuration of panelizer to Feature?

I've gotten this as well and have done some investigating that might help us push forward on this a bit.

I think the crux of the issue is as merlin describes. Features usually gets defaults from the exported code and diffs them against any overriden values in the database. With panelizer there is this intermediary state where you have a panelizer "default" that is neither in exported code nor in the database. What ends up happening is features thinks these intermediary "defaults" are actually in code even though they are not.

You can try this to see what I am throwing down:

1. Create 2-3 panelizer defaults. Make sure at least one of them is in the DB.
2. Make sure that you are not exporting any other panelizers and then export one of the panelizers defaults into features.
3. Go back and check the status of your feature. You will see that it is overridden.
4. If you have the DIFF module installed you can see that it lists all your other panelizer defaults as "default" (which in features land means presumed to be in code). This is confusing to features because these "defaults" are not actually in code. Even if one of these panelizers is listed in the DB it will show you the settings for the panelizer default and not the overridden settings in the panelizer defaults DB table.
5. Since features now thinks this feature has all the other panelizer defaults in code, it will not allow you export other panelizer defaults in another feature.

I've looked into PanelizerEntityDefault.class.php which is where the defaults get produced for features and as far as i can tell it works how it is supposed to....

@merlin, do you think it would make more sense to put some kind of check or conditional in there or to try and catch this when its passed back to features? It sort of seems like a square hole round peg problem with this "true default" intermediate state so maybe it would be better for features to parse this out?

Pardon whatever sort of incoherent babble is about to unfold in front of you but it's 3:30am here and i am all sort of caffeined up. That being said, I think i've got a decent handle on what is going on here but i require a little more guidance in terms of how to best implement a fix.

This is a little bit of a simplification but when features is checking for overrides it compares the current state of a component vs the default state of the component. It does this using two functions which are features_get_normal and features_get_defaults. For panelizer both of these functions end up going through panelizer_panelizer_defaults_alter(). This makes sense for features_get_normal but when it runs for features_get_defaults it is adding in all of the not-in-code/not-in-DB panelizer defaults to the list of feature defaults. This makes it seem as though these defaults are in code in some feature while they are really not. It should be relatively straightforward as to why this would be problematic.

@merlin, or someone else will have to verify this but i am not sure that panelizer_panelizer_defaults_alter() needs to run at all for features_get_defaults. I have not tested this extensively but it does seem that the desired functionality is achieved and the issue resolved when panelizer_panelizer_defaults_alter() is not run for features_get_defaults.

The question now becomes how best to tackle this problem. Features lets you set a key called "alter_type" on each component type, although it does not seem to be used by many, if any, other modules. If you set this to "none" it will bypass the drupal_alter call for that component in features_get_defaults, in this case panelizer_panelizer_defaults_alter() which seemingly produces the desired functionality. This key can be set in hook_features_api, however given that ctools has its own handling mechanisms for these things i'm not sure the best place to override hook_features_api for individual ctools exportabes... maybe it's fine to just do something like this.

/**
* Implements hook_features_api().
*/
function panelizer_features_api() {
  $api = array();
  $api['panelizer_defaults'] = _ctools_features_get_info('panelizer_defaults');
  $api['panelizer_defaults']['alter_type'] = FEATURES_ALTER_TYPE_NONE;
  
  return $api;
}

Using this key seemed like the easiest (but perhaps not best) approach, whether it is in a normal hook like above or whether it is set in a more ctoolsy way. Let me know what you guys think and if there is a general consensus here i can provide a patch.

Either way and at the very least you can drop the above into a custom module and use it as a workaround for now.

just for the hell of it i threw together a patch if only to try to push this along a bit. still hoping there is a more ctoolsy way to do this. Also, changing this to 7.x-3.x-dev.

Patch fixed my issue, thanks Pirog!

I don't understand the features API well enough to review this. I have two reports that it works, and from my side I don't have any problem with it. I'd love it if I could get another couple of reports from people who use features + panelizer together?

I use panelizer a lot for my things and this patch certainly helps with the exporting process, but there seems to be some wierd interactions between different types of exports. For example, when I tried to export my panelizer setting for my user profile I ended up with an export for a node type!

That's a bummer. Let me try to replicate.

tried to replicate this and was able to export panelizer settings for users and taxonomies without the behavior you are describing. any suggestions on how to reproduce this?

I was able to replicate it again this morning, attached is my Panelizer settings (all in code) and the output of what krumo is showing me as being passed out of the hok_features_api(). I believe if you just install the latest version of Panopoly, add the Panopoly FAQ module, and then try to export the panopoly_users feature you will see the problem.

This patch is *so simple* that I did some more digging and believe that #1555194: Remove did from panelizer exports is relevant to your interests. I agree it is worth having someone with features experience look at all of this, but my issue went away when I applied both patches in question.

i've definitely also noticed issues with the display id before, regardless of whether the patch in this issue is applied or not.

i think this is symptomatic of a general "problem" with features aka ids can be different across sites so when the id's don't match you end up getting the crap for the wrong id. this caused similar problems when you tried to export non-machine-named blocks with features in D6. If you remove the id on export i think the featurized panelizer is assigned an id dynamically when you install the feature and this prevents the id collision/mismatch scenario.

with regard to this patch: the simplicity is indeed kind of surprising but it does prevent features from getting the wrong default states of panelizers. the only question i would have for features people is it doesnt really look like anyone else is using the "alter_type" key at all so while it does that its supposed to do... do we want to use it?

yeah, now that i am looking at this more, i can see why i couldn't reproduce your error.

However, if i have a panelizer in code with display id x and then i create another panelizer which is temporarily stored in the database it very well might also have display id x and if it does and i try to re-export the panelizer in code it will grab the data from the display id that is in the db (the wrong one) and attach it.

@populist: does this sound about right?

Okay, I think I see how this works.

If this is the case, then there's a bunch of code in PanelizerEntityDefault::hook_panelizer_defaults() that we can simply remove.

And by 'bunch of code' I mean the specific code that prevents showing defaults that are in the database; that'll remove the query in the method and the test against the results of the query.

Here is an unified patch (against dev) of a number of the fixes in this thread and also in #1555194: Remove did from panelizer exports which I closed as a duplicate and referenced here. I am also updating the title / category here to be more clear about what is going on. The goal here is to produce support with Features that allows:

• Panelizer should export its settings cleanly (i.e. they don't show up as overriden later)
• Panelizer settings should not conflict with each other (i.e. dids could overlap and cause problems)
• Panelizer exports should work for nodes, taxonomy terms, or users

Committed and pushed. Remember that the schema update requires a cache clear.

This patch also applies cleanly to the current 7.x-2.x branch, and successfully resolved my issues with panel exports.

The diff to the subsequent export was only the removal of the panelizer display id entries, and after that features was no longer getting those panels mixed up with node_view panels.

Marking nr for 2.x then.

This appears to work really well.

I tested it on a site that had both single and multiple Panelizer defaults for specific content types, which were encapsulated in individual features per content type & display. The site had a running problem that many of the node:*:default defaults would disappear during export. After applying the patch I updated all of the content type features via Drush and the main change was that the $panelizer->did values disappeared; I did have other issues with one of the defaults but I suspect something else was at fault.

This looks good.

I've committed the patch to 7.x-2.x as merlinofchaos had already blessed it on 3.x and it proved to work well in my tests.