Features are duplicated after update

I think this only affects it when using the install profile option. Also, not sure what you mean in #2 by "without patch".

After you install Drupal, can you check your site to see if you actually have multiple copies of your various feature modules? Do a global search and see where the modules are found.

If you are seeing two different machine names like "core" and "mybundle_core" then check to see if you really have two modules (one named "core" and one named "mybundle_core") in your filesystem.

Also, could you take a screen shot of the Features page and expand two of the duplicate features (like Article) so we can see which config is duplicated.

Moving this to "normal" because I'm not seeing this behavior during normal individual feature export or import and creating an install profile is only one type of workflow that a limited number of people use.

In the meantime, I'll try to run through your actual procedure, but that will take a while for me to get to. Any other people who could help test/debug this issue would be welcome.

I also am experiencing this issue.

I verified that there are not multiple copies in code. I also tried uninstalling and recreating the feature. The feature then shows up twice after updating.

I did not create the features as a profile.

The only differences in the included configuration between the two are the dependencies. Here is a side-by-side of the two:

So far, I haven't seen any ill effects from this.

dobrzyns: Since you said you see this without creating a profile and just uninstalling/recreating, can you post a step-by-step procedure for this?

I should note that the side by side image I uploaded is for a content type.

1. Installed with minimal profile.
2. Exported config with drush cex
3. Added subtheme, enabled, set theme settings.
4. Exported config with drush cex
5. Added config_installer (profile)
6. Installed site from config
7. Created content types, custom block types.
8. Created features and enabled.
9. Made some changes (added/removed fields).
10. Using the UI, I updated the features using the "Write" action.

Interestingly, after the above steps I:

1. Ran drush cr
2. Recreated features through UI using "Write" action.
3. Ran drush cr

Now, only one feature is duplicated. I tried the above steps a second time, and the same feature was still duplicated. Here's the side by side:

Again, the only difference is the dependencies.

OK, you are still missing some steps. I don't need all the steps from creating your initial site, but I need more details on the features you created. The screenshot shows a module called "pmg_show_sites_global_core". I need to know exactly how this module was created. Did you create a new bundle? If this is the only module that is duplicated I need you to expand your step 8 on how it was created. Also, if you use the Write button without making any changes, does it still get duplicated?

Still have not been able to replicate this.

Ah ha!, I reproduced it.

So the key is that you have to use the Write button from the main Features listing page. If you Edit the feature (or Create a new feature) and click Write from the Feature Edit page, or if you use "drush fu" to export the feature, then it doesn't duplicated.

The cause of this is the lack of the "required" section in the mymodule.features.yml file when using Write from the main page. Nedjo had a use-case where he wants config to be able to "float" between auto-detected packages when writing features from the main page. And when there is an existing feature the config assigned to it gets reassigned by the assignment plugins because the "Existing" plugin runs last.

I have often advocated for running the Existing plugin *before* the other plugins but we haven't come to agreement on this. But you are running into one of the side-effects of this which is that the BaseType assignment plugin is creating a package called "Article" that grabs the article configuration even though it's already assigned to your mybundle_article package module.

Before the commit that caused this, the "mybundle_article" module was being converted and stored internally as the shortname "article", which matches the package created by the BaseType plugin. But in order to support multiple packages with the same shortname, the commit now stores it internally as "mybundle_article" which then causes the duplicate of article.

Let me investigate possible solutions to this, but we might need Nedjo to chime in to help with this. It's another case where the whole shortname/longname/bundle stuff is just making this too complicated for people.

Thanks all for the detailed explanation of the bug.

I think we may need to revert #2745023: Features Drush commands are using shortname instead of the expected module name (fullname) and solve that issue a different way. Specifically, in the drush commands, we can parse the bundle from a prefixed feature name and then pass the short name as prior to the commit in #2745023.

Adding some related issues from the past: #2596047: Duplicate packages generated, #2490888: 'existing' assignment plugin runs too early

We've been down this road before and are going in circles.

Nedjo: No, the issue in #2745023: Features Drush commands are using shortname instead of the expected module name (fullname) wasn't just for Drush. It also solved: #2771919: Reuse the same machine name across bundles which is the more important issue.

Okay, hadn't seen the relationship to #2771919: Reuse the same machine name across bundles. I'll have a look at this today.

@mrpotter Sorry about not expanding on step 8. I did change the bundle after the feature through the UI on the edit page (admin/config/development/features/edit/core) and then renamed the files, so that could play a part. (Unfortunately, I don't have the time to test right now due to project demands.) Uninstalling the feature module, deleting the files, and re-creating worked. There was not a duplicate then after updating using the "Write" action on the edit form for the feature.

OK, Nedjo and I had an IRC discussion on this and came to the following conclusions:

1. Moving the "Existing" plugin higher in the list (running earlier) would allow existing config to remain in existing exports without needing the "required" flag
2. This would prevent duplicate packages and prevent config from moving around
3. In #2490888: 'existing' assignment plugin runs too early we talked about this in the past and invented the "required" flag as the solution. So by moving "Existing" plugin we might be able to do away with the complexity of the "required" flags.
4. For people who want config to get automatically reassigned as plugin options are changed (like nedjo), they just move the "Existing" plugin to run later in the list
5. Would be useful to write some tests that test both use-cases (moving the "Existing" plugin around)
6. Also possible that some of the complex options of the Excluded plugin could be removed or moved to the Existing plugin

I'll dig into all of this tomorrow and start with some tests for all of this. First step will be a test that fails with the existing version because of the duplicate modules. Then I'll move the Existing plugin and write an update hook that moves this for any existing sites using the default config settings. Then I'll play with the "required" flags.

Thanks to everyone from bringing this to my attention and getting it reproduced. Moving this back to a Major problem to be fixed before any RC release.

Did some initial sleuthing.

Setup:

• Install core with the Standard profile.
• Install Features and Devel.
• Create a custom features bundle, mybundle1.
• Export two of the automatically detected features, mybundle1_article and mybundle1_comment.
• Create a second custom features bundle, mybundle2.
• Export mybundle2_article.
• Select mybundle1 as the current bundle.
• Navigate to admin/config/development/features. The feature mybundle1_comment shows twice, once without a corresponding checkbox.

At devel/php, enter the following code.

$assigner = \Drupal::service('features_assigner');
$assigner->assignConfigPackages();
$manager = \Drupal::service('features.manager');
$packages = $manager->getPackages();
dsm(array_keys($packages));

Result:

Array
(
    [0] => mybundle1_article
    [1] => mybundle1_comment
    [2] => mybundle2_article
    [3] => page
    [4] => user
    [5] => core
    [6] => site
)

The exported features are keyed by full name, while remaining ones are keyed by short name.

It appears that the duplicated items are those that (a) are exported for the current bundle but (b) are not exported for any other bundle.

Here is a really simple patch to just fix the duplicate module issue. This doesn't have any of the more extensive refactoring. Turns out it was just a problem when detecting the existing feature modules.

What it's doing is first creating a bundle_article package (to match the existing module), then the Base Type plugin creates a generic "article" package based on the content type. This was all fine. If "article" never ends up with any config assigned to it (because it's excluded) then it gets removed from the packages list (as an empty package).

However, when the Base Type plugin was detecting if an existing module was found, it was matching the full-name (with bundle) rather than just the machine name. This patch fixes that and a similar issue in the Excluded plugin for determine if the config was assignable.

Please test and see if this patch resolves the issue.

Grimreaper: Thanks for the testing results! The duplicate you showed in your screenshots is actually a valid one I think. In the second "unexported" feature, it it showing configuration that it suggests should be part of your existing "core" feature. Unlike the bug that the patch fixes, it's not actually duplicating the contents of the feature. It's more like "here is some stuff that you might have forgotten".

Yeah, it's still technically a usability issue since you can't easily "merge" the suggested package with your existing package. The components marked as "new" in the existing feature are from the dependency detection where as the components in the un-exported package are from the Core assignment plugin.

OK, here is a patch that adds a test. The test fails without the fix from #16 and passes when the fix is applied. It doesn't test the duplication directly but instead checks to ensure the Extension object is only assigned to the proper package instead of both packages which was preventing the empty package from being removed.

Committed to 392ef38.