oa_config feature override conflicts [#2411183]

I made some changes to the WYSIWYG buttons and Linkit through /admin/config/content/wysiwyg and /admin/config/content/linkit. As expected, this caused OA Config (and Panopoly WYSIWYG) to show as overridden. I viewed each of those to see what was overridden and then added those items to a new feature. I added:
filter.panopoly_wysiwyg_text
linkit_profiles.content_editors
wysiwyg.panopoly_html_text
wysiwyg.panopoly_wysiwyg_text

I created my feature and enabled it. Unfortunately, now instead of OA Config showing as default, it still shows as overridden and claims to be in conflict with my override in features_override_items [filter.panopoly_wysiwyg_text, wysiwyg.panopoly_wysiwyg_text]. I am also not able to revert the overridden items in Open Atrium Config. Is there a way to save my edited WYSIWYG and Linkit configurations, or is this another one of those situations where feature overrides don't work well with panopoly. I guess I could clone the configurations and make new ones, but then if I assign the new one to my user roles with that create an override by itself and put me back in the same boat? Thanks for your help.

Comments

Comment #1

nrackleff CreditAttribution: nrackleff commented 21 January 2015 at 00:52

Issue summary:

View changes

Comment #2

mpotter CreditAttribution: mpotter commented 21 January 2015 at 13:55

I believe the issue here is that StrongArm doesn't work well with Features Override (Strongarm is used to featurize system variables). The OA Config module is meant to work as a default for OA2. I'd recommend cloning OA Config to your own Site Config module and then disabling the OA Config. You'll just need to keep an eye on changes to OA Config in the future to update your site config with any new settings.

Another alternative to handling overridden variables is to set the variables in your settings.php, or in a custom code module, or in your site deployment scripts via drush. That will still cause the OA Config module to be marked as Overridden but you'll be able to safely do a features revert without worrying about losing your changes.

Comment #3

nrackleff CreditAttribution: nrackleff commented 21 January 2015 at 18:03

Thanks for the advice. If I go the route of cloning the module and turning off the Open Atrium version, do I just let the cloned version remain overridden when I make changes through the admin interface, or do I need to incorporate the changes into the cloned module? Thanks again for your help.

Comment #4

JKingsnorth CreditAttribution: JKingsnorth commented 10 September 2015 at 14:49

Status:

Active

» Fixed

If you wanted to go down that route then you could clone oa_config, make the changes in the admin interface and then 'recreate' the cloned oa_config module and re-upload it. Then it will capture your changes. But I imagine doing that would make it much harder to update OA, because you'd need to then merge your changes in oa_config_clone back into the new oa_config feature. (As mpotter mentioned).

In the latest version there shouldn't be any 'overridden by default' features, so I'm going to mark this as fixed =]