Problem/Motivation
Currently it's necessary to manually enter a machine name for each features override. Usually, though, a feature developer will want to use a naming convention. Also, the requirement for manual naming blocks automated override export, #1314662: Provide drush and UI methods for mass exporting overrides.
We need to support multiple or chained overrides to a given component, e.g., I install a distribution that includes an override of a view and I want to save additional changes to that view. So we need the ability for an override, or a set of overrides being generated, to have a custom name part so it won't conflict with other overrides of the same component.
Proposed resolution
Provide default names for override components. Likely this should be based on a configuration option with token support. Possible default for machine name:
[override_set_name]_[component_type]_[component_name]
where [override_set_name] is the configured name of a set of overrides to go into a new feature. E.g., If I'm generating an override of a view with machine name 'event' for my local install of open atrium at example.org and have configured the override_set_name to be 'example', the override would be: example_view_event.
Comments
Comment #1
fagoI'd vote for using a fixed naming scheme like:
>[overrides][component_type][component_name]
If you specify it in an .info file, you'll get the overrides of those component without any prior configuration.
Comment #2
nedjo@fago: I'm thinking we need to support multiple or chained overrides to a given component, e.g., I install a distribution that includes an override of a view and I want to save additional changes to that view. So we need the ability for an override, or a set of overrides being generated, to have a custom name part so it won't conflict with other overrides of the same component. If I'm generating an override of a view with machine name 'event' for my local install of open atrium at example.org, I guess a useful name would be: [override_set]_[component_type]_[component_name] or example_view_event.
Could you explain more about your .info file idea? What would we put in which .info file?
Comment #2.0
nedjoUpdated issue summary.
Comment #3
nedjoPostponed pending the work outlined in #1316940: 2.x Features Override using new Alter method. May not be needed after that issue is complete.
Comment #4
matglas86 commented+1 here. I stared using this module today and thought "How do I have to do my naming?". Now I created about 5 overrides with general names like "Action - view override". Now I realize that that is the wrong way to go. These names are not even correct for machine names.
Shouldn't this also have filter for a good machine name like machine name input field?
I hope to see this feature in here in the future.
Comment #4.0
matglas86 commentedUpdated issue summary.