Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'd like to do an audit to ensure we didn't pipe in unnecessary field components and include them in exports.
Comments
Comment #1
ezra-g CreditAttribution: ezra-g commentedRelated issue: #1868698: Prevent Commons field instances from being piped into Feature exports.
http://drupalcode.org/project/commons_radioactivity.git/blobdiff/5fc9285...
Comment #2
ezra-g CreditAttribution: ezra-g commentedhttp://drupalcode.org/project/commons_groups.git/commit/aa1e062
Comment #3
ezra-g CreditAttribution: ezra-g commentedhttp://drupalcode.org/project/commons_groups.git/commit/aa1e062
Comment #4
ezra-g CreditAttribution: ezra-g commentedLooking 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.
Comment #5
japerryComment #6
ezra-g CreditAttribution: ezra-g commentedIt 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.
Comment #7
ezra-g CreditAttribution: ezra-g commentedWe'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.
Comment #8
japerrywent 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.
Comment #9
ezra-g CreditAttribution: ezra-g commentedI'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).
Comment #10
ezra-g CreditAttribution: ezra-g commentedI 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
Comment #11
ezra-g CreditAttribution: ezra-g commentedAnd, fixing a syntax error that caused the patch to fail: http://drupalcode.org/project/commons.git/commit/ff19869
Ahem.