I'd like to do an audit to ensure we didn't pipe in unnecessary field components and include them in exports.
Related issue: #1868698: Prevent Commons field instances from being piped into Feature exports.
Looking over the features that are currently overridden, it appears that most of the overrides are caused by the addition of the administrator role to Commons -- We should just re-export these features and commit updates that include the new admin role. Many others are caused by the RDF exports added by the rich snippets module. We should either prevent that module's output from appearing in feature exports, or more likely, simply re-export the affected features.
It looks like message_subscribe_email is the only overridden feature on a fresh install currently. Getting close!
We probably just want to unset the components it exports from being rendered.
We've also got multiple instances of the og_group_ref field appearing in info files for commons content type modules, when it should not appear there.
Edit: False alarm, these were old features_exclude lines.
went through and audited the flags for email subscribe, held within various commons modules.
The way I suggest we proceed is to remove the email_* flags from the commons features, because they're missing the bundle (as designed), which means they should not be enabled by default. If there is a compelling reason to enable these on install, we can do that, but we also need to specify which bundles the flags should be attached to.
Either way, the flag export is exactly the same in message_subscribe_email as each of the commons modules, so we should use their exported flags, and enable on install with corresponding bundles -- or leave disabled and let the user enable the email notifications if they wish.
Either way, the flag export is exactly the same in message_subscribe_email as each of the commons modules
I'm not sure that's accurate. The machine names are the same but the flag properties are different (eg, the flag, unflag text in the email_node flag). We could certainly alter the default flags defined by message_subscribe_email if that's an easy approach).
I was able to prevent the Message_Subscribe_Email feature from being overidden by re-rolling the patch to Message Subscribe at #1915364: Remove unnecessary Features lines from message_subscribe_info file, and reverting a commit to Commons Follow that removed most of the email_* flag definitions but left the email_group one in place. So, this puts is back in the situation where commons_follow* define the relevant email_flags being used and they are enabled with the expected content types on a fresh install.
Now, drush features-list shows that all features are in their default state on a fresh install - I believe the present issue is fixed.
Reverted commit to Commons Follow: http://drupalcode.org/project/commons_follow.git/commit/1d8c104
Message Subscribe patch added to Commons:http://drupalcode.org/project/commons.git/commit/f9c9513
And, fixing a syntax error that caused the patch to fail: http://drupalcode.org/project/commons.git/commit/ff19869
Automatically closed -- issue fixed for 2 weeks with no activity.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.