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

fago’s picture

I'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.

nedjo’s picture

@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?

nedjo’s picture

Issue summary: View changes

Updated issue summary.

nedjo’s picture

Status: Active » Postponed

Postponed pending the work outlined in #1316940: 2.x Features Override using new Alter method. May not be needed after that issue is complete.

matglas86’s picture

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

matglas86’s picture

Issue summary: View changes

Updated issue summary.