How often did you have the case when the contrib module provided some very nice sane defaults which were used as a base for further customization? Me personally — a lot.
Not sure what I mean by that? Here is a simple example.
You install Commerce and want to do a basic Tax (Vat) calculation. For this specific case we have the Tax UI sub-module which allows creating simple tax types and rates via Rules.
You go to
/admin/commerce/config/taxes/types, click on Configure rule and modify a rule by adding a condition for the rule to be applied only for specific payment types. In my case the rule shouldn’t be applied for the Points payment type.
Things go very well until the point where we need to store and export our overrides, most probably in a Feature.
You may think that going to the existing feature (or creating a new one), and locating our modified rule in the list of other rules will cut it, but it won’t.
Problem is that the rule is defined in
\commerce_tax_rules_action_info() with the default configuration for it described in
\commerce_tax_default_rules_configuration() and the maximum we could achieve is that the Rule status will become Overriden, indicating we've modified it, but it won't help us to make it exportable.
Unlink the default configuration of the rule in question from the code and move it to the database. Which is exactly what the Unlink default configurations module does!
Install the module, go to
/admin/structure/unlink_defaults, in the Rules section locate our rule, check it and save. Simple as that.
The rule will immediately be available in Features and won’t cause you any further trouble.
There are many other cases which you might want to explore (unlinking views, page manager and entities configurations) and I hope that very soon you won’t imagine your life without this handy utility module.