Check if similarly namespaced module exists before recommending config items to export [#2784579]

We're building a site that has many related content types, and the machine names for these are very similar. i.e. we have a "brochure" and a "brochure_list" content type. When exporting/updating the shorter named Feature, config items from the longer name often appear. The config items that seem to be erroneously grabbed most often are the core_entity form and view displays, sometimes the extra content-type user roles (generated from Lightning), and occasionally fields(/storages) from the longer type.

I don't think this is necessarily incorrect behavior, because the full machine name of the first exists in the second. It makes sense that Features would try and add "brochure_list" config items to the "brochure" export, because it's looking for "brochure" config items, and "brochure_list" matches that pattern.

While that may not be functionally wrong behavior, it is annoying, especially because we have about ten or twelve of these content type pairs already. If feasible, Features could either match suggested config exports to machine names more strictly, or do some sort of check for machine names that match but should/do exist as their own thing, to exclude config that would be better stored in the more specific module.

Comments

Comment #1

15 August 2016 at 22:54

tjh created an issue. See original summary.

Comment #2

nedjo

he/him/his

English

CreditAttribution: nedjo commented 16 August 2016 at 16:44

The namespace package assignment plugin calls FeaturesManager::assignConfigByPattern(), which includes the following:

    $config_collection = $this->getConfigCollection();
    // Reverse sort by key so that child package will claim items before parent
    // package. E.g., event_registration will claim before event.
    krsort($config_collection);

So, we're attempting to ensure that more specific package namespaces are matched first, but it sounds like this isn't happening.

Comment #3

tjh CreditAttribution: tjh at Phase2 commented 18 August 2016 at 23:13

After some further investigation today, this only seems to happen if the short package namespace does NOT have anything related to the longer package namespace in the excluded: section of short_namespace.features.yml

e.g.
It appears if brochure has ANY reference to excluding config meant for brochure_list, FeaturesManager::assignConfigByPattern() will properly get called. As long as one config item for the longer namespace is told to be excluded, it appears to respect that for all items in the namespace.

bundle: our_bundle
excluded:
  - core.entity_form_display.node.brochure_list.default
  - field.field.node.brochure_list.field_name
required: true

Will correctly leave ALL config related to brochure_list out of the 'suggested items' for the brochure package.

If the excluded: section of brochure.features.yml is missing or has nothing related to brochure_list, it appears to be hit or miss whether items are correctly excluded or not.

Comment #4

mpotter CreditAttribution: mpotter at Phase2 commented 2 September 2016 at 18:17

Status:

Active

» Postponed (maintainer needs more info)

There have been several issues fixed in the past few days, some around the "excluded" flags.

I created a content type called "new_page" and another content type called "new_page_test" and then added various fields. I couldn't get it to fail and never saw a cross-mixing of items in either feature.

So, try the latest dev (or the forthcoming release) and test it again. If you can still find a problem, post a step-by-step procedure for reproducing it.

Comment #5

kriboogh CreditAttribution: kriboogh at Calibrate commented 18 November 2016 at 13:53

Donno if it's related, but we have a content type (machinename=example_a) which is exported in feature (machinename=feature_a). We also happen to have a second feature which is named the same as the content type machinename (=example_a).
When we create new fields for the content type, the field configs are named: field.field.node.example_a.field_name
This results somehow in these configs being listed in the wrong feature. They should be listed in feature_a, but because the content type in the field config matches the second feature they are listed there. We can only add them in feature_a if we allow conflicts.