Hello,

I'm busy creating a distribution based on Panopoly. Thanks for your hard work on Panopoly, it's working really well for me!

I'd like to know what the best practice is if you want to have some configuration in your distribution that overrides Panopoly features. I see that I could use the feature overrides module, but then what if one of the sites created from my new distribution needs to make more changes. That would mean overrides of overrides. Messy! Here's an example:

Creating the distribution:

  1. Add a new vocabulary 'VocabX'
  2. Add a field for VocabX to the panopoly-page content type (Content Page)
  3. Add the field as a filter to the view Panopoly General (so it can be used in the panelizer IPE content modal
  4. Note that the features Panopoly Pages and Panopoly Widgets have been overriden
  5. Use features overrides in a new feature 'FeatureA' to store the overrides to Panopoly Pages and Panopoly Widgets in code

Creating a new site from the new distribution:

  1. Add a new vocabulary 'VocabY'
  2. Add a field for VocabY to the panopoly-page content type (Content Page)
  3. Add the field as a filter to the view Panopoly General (so it can be used in the panelizer IPE content modal
  4. Note that the view in the overrides feature 'Feature A' has been overriden
  5. Figure out how to deal with the override to get it in code.

Other than the above method I think I have a few options:

  1. Create patches for the 'Panopoly Pages' and 'Panopoly Widgets' modules instead of using features override.
  2. Copy the Panopoly Pages and Panopoly Widgets features, turn them off and use the copies - with changes - instead

With both these methods the initial state when creating a site from my distribution would be non-overriden. Meaning that features override could safely be used.

Any advice greatly appreciated!

Andrew

Comments

Andrew Edwards’s picture

Issue summary: View changes
Andrew Edwards’s picture

Issue summary: View changes
Andrew Edwards’s picture

The approach I ended up taking was:

1) I turned off the Panopoly Pages feature and created my own similar feature for content types.
2) I altered the view 'Panopoly Widgets General Content' using hook_views_default_views_alter() in my own module.

That way, any sites created from my distribution can use 'features override' without overriding an override. If you know what I mean.

It would seem overkill doing the above, I think, if there were only a few small changes. I had enough going on to justify the work and the longer future update time though.

Any thoughts appreciated!

dsnopek’s picture

Status: Active » Fixed

Sorry to revive such an old issue, but I just found this when looking for something else. :-)

I think the approach you chose in the end was good. Panopoly is made up what I'd call "opinionated" Features and "general" Features. Panopoly Pages in an opinionated Feature, in that what it does has a certain use-case in mind and what you might want to do for your sites could be totally different. So, not including Panopoly Pages in a child distribution, and then making your own Feature that creates the basic content types is a totally normal thing to do.

Panopoly Widgets on the other hand, is a "general" Feature in that it makes no assumptions about your use-case and is meant to work with any kind of distribution. When needing to override specific widgets, I'd recommend either:

  1. Using Features Override or manually writting alter hooks (like you did), or
  2. Disabling specific widgets (which you can do by altering a variable or using an alter hook) and providing your own alternative widgets

This way, you still get to take advantage of new features and bug fixes that we make to the parts of Panopoly Widget that you do use.

I hope that helps!

Andrew Edwards’s picture

Thanks @dsnopek!

I can confirm that the methods I used are working well. No maintenance issues at all.
Thanks for the advice on disabling specific widgets as well. I hadn't thought of that, and I think it could end up being a neater solution than using alter hooks for my use case.

Thanks also for all your great work on Panopoly. Truly appreciated!

Status: Fixed » Closed (fixed)

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

UTAN_dev’s picture

In a comment to "Feature Strategy for Panopoly Child Distribution" over at the Panopoly group, David expanded on his concept of "opinionated" and "general" Features, listing which Panopoly Feature belongs in which group. I recommend that thread as a followup to those wondering how best to handle overriding Panopoly.