I'd like to do an audit to ensure we didn't pipe in unnecessary field components and include them in exports.

Comments

ezra-g’s picture

Title: Audit Features Info files » Audit Features for cruft
ezra-g’s picture

ezra-g’s picture

Title: Audit Features for cruft » Audit Features for cruft & overrides on fresh install

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.

japerry’s picture

Assigned: ezra-g » japerry
ezra-g’s picture

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.

ezra-g’s picture

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.

japerry’s picture

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.

ezra-g’s picture

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).

ezra-g’s picture

Assigned: japerry » Unassigned
Status: Active » Fixed

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

ezra-g’s picture

And, fixing a syntax error that caused the patch to fail: http://drupalcode.org/project/commons.git/commit/ff19869

Ahem.

Status: Fixed » Closed (fixed)

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