I have a problem with a view featured into many feature. I do that because I have 3 web site with the same view but i have some change on each web site.

When i'm into the features dashboard only the first feature with the view have the button modify every time... It's the first problem. I install only one of the 3 features on each instance. Then it's not normal that feature test on the first feature where he found my view. I think that feature don't need to test uninstall feature...

The second problem is that when I click on modify i see the difference between the last views on my list (It's the same, it check on an uninstall feature).

To reproduce:

  • Create a Drupal with feature
  • Set 3 hostname on this instance
  • Create a simple views
  • Duplicate feature for each instance with a new name (feature_1, feature_2, feature_3)
  • Install feature on each other instance
  • Change something on this view on the second instance and same for the third feature and instance.
  • Check feature panels modification and you have the same problem that i have
    • feature_1 : have modification specify to the first feature and when you click on modify you see the third feature change (feature_3)
    • feature_2 : have modification specify to the first feature (uninstall) and when you click on modify you see the third feature change (feature_3)
    • feature_3 : have the rigth feature.

Hope anyone can do anything for me.

PS: Sry for my english

Comments

noita created an issue. See original summary.

noita’s picture

Priority: Major » Critical
noita’s picture

Title: Problem with different feature comprising the same view » Problem with different feature comprising the same view (multi-site support)
noita’s picture

StatusFileSize
new8.59 KB

Hi Guys,

I have create a patch with all change that I have test on my instance.

This patch change some element :

  1. When you define table list of folder (getAllFolders from FeaturesInstallStorage.php) : I test if module exist to not override existing value with disable module => this part is necessary when you are in diff, you check on disable module.
  2. I filter diff form by installed module, I remove uninstall module => You wan't apply an uninstalled module change...
  3. On the table, I remove moved or other link when the module is disable (Path is not correct, that correct this part) => I have message move this part in a common module and not in the first disable module
  4. I return an empty detection id the module is disable (FeaturesManager all detect function) => I don't need to detect a disable module
  5. I add a filterPackages function in interface and in class to use syntax use before

I hope that's a good solution ...
And hope to ave your return quickly :)

PS: Sry for my english

noita’s picture

StatusFileSize
new8.71 KB

I just change hard coded number by the constant.

noita’s picture

Anyone to respond to this problem ? ( Use this patch in production and want to have your return about that )

RAFA3L’s picture

I think you can't set the same view into multiple features

noita’s picture

You can set the same view into multiple features. But if you need to use only one of them, you can't. If you try to use active feature to select it that didn't work. That's what I explain to the first part of this post (Sry my english is not really good).

Feature don't use activate feature to define the views that need to be set. My patch allow to disable or activate features and set the right views.

noita’s picture

StatusFileSize
new8.36 KB

Hi,

My patch is not. I have create a new patch usable with composer.

This patch is a git diff (I use phpstorm and then I have create my patch with him before this one).

Now, I use it with composer like that :
"patches": {
"drupal/features": {
"Drupal features patch": "../patches/multi_site.patch"
}
}

Thanx for your reply

botanic_spark’s picture

I have a similar problem where I have one view in two features (only one feature is enabled) but features are detecting configs in uninstalled one, which makes impossible to import config from correct one.

After short testing, looks like patch #9 solves the issue for me.

botanic_spark’s picture

+++ b/src/Plugin/FeaturesAssignment/FeaturesAssignmentExclude.php
@@ -33,7 +33,7 @@ public function assignPackages($force = FALSE) {
+    $config_collection = $this->featuresManager->getConfigCollection(TRUE);

Is there a reason why we are forcing this? If set to TRUE, it gives errors when reverting features.

noita’s picture

StatusFileSize
new11.52 KB

Hi sry for the long wait of my reply; I set it to true to be sure that I have the last configuration. That reset the configuration. What is your error ?

I recreate a patch that work with the new version of the module. I use it like that:
- First, that require cweagans/composer-patches (composer require cweagans/composer-patches)
- Second, I set a patches section to the extra part in the composer.json

Part of code:

        "patches": {
            "drupal/features": {
                "Support multi site features": "web/patchs/feature_multisite.patch"
            }
        }

After that use "composer update" to refresh the module with the patch.

weynhamz’s picture

Nice work, this patch should definitely be included.

With a multi-site setup, sometimes we need to export certain configuration into different features/modules, and only one of those modules will be enabled per site. Current Features module checks all the modules, despite if it is enabled or not, and if a configuration exported to multiple modules, it shows a 'Moved' state for the feature, this is fine in single site setup, but for multi-site setup, only enabled modules should be checked against, and this patch comes to rescue. Thanks.

jasonawant’s picture

Status: Needs work » Needs review

Changing to Needs Review in attempt to get maintainer's attention and feedback.

It's explicitly stated that FeaturesInstallStorage::GetAllFolders() "Load all modules whether installed or not", see here.

I've traced that change back to #2532452: Refactor FeaturesInstallStorage. Though, that issue does not state why it is discovering config from uninstalled modules.

nedjo’s picture

Title: Problem with different feature comprising the same view (multi-site support) » Features scans uninstalled extensions for config
Priority: Critical » Normal

Thanks for your work here.

First, to clarify, the issue here appears to be that features is scanning uninstalled extensions for configuration, which is leading to unexpected results. I'm changing the issue title to clarify.

Please see my comment in #2668562-27: Not detecting overrides in profile config files:

If we can remove complexity rather than adding new complexity that would be ideal. Before going ahead, I'd like to understand the use case for scanning uninstalled extensions.

The same applies here. If we can't identify a clear use case for scanning uninstalled extensions, we should remove it rather than adding more complexity to work around it.

nedjo’s picture

Returning to the original report:

I have a problem with a view featured into many feature. I do that because I have 3 web site with the same view but i have some change on each web site.

Are the three modules in different features bundles? If so, we may be able to address this issue. But if they're part of the same features bundle, then the fact that doesn't work is by design. Each config item can only be assigned to one feature in a given bundle. (Yes, I know there's a conflict mode that was introduced that allows you to re-add a config item that is already provided by a different module. But, aside from the special case of install profiles, which are allowed to override config provided by other extensions, a given item cannot be provided twice, hence should not be packaged twice on the same site, or at least not in the same feature set.)

Okay, on to the question of why we're scanning uninstalled extensions.

Theory: the reason we scan uninstalled extensions is that we don't want to end up duplicating them.

Say I:

  1. Install Features.
  2. Create a new bundle.
  3. Generate all features in that bundle.
  4. Go back to edit the bundle.

At that point, it makes a difference that the features exist on the file system. When I first created the bundle and the package assignment plugins assigned config to various packages, they were just theoretical features--they didn't exist yet. But now they're not just theoretical features that could be generated--the actually exist.

So when I return to view my bundle through Features UI, I don't want to see them as features that could be generated. I want to see them as the actually exist--despite the fact I haven't (yet) installed them.

But - and this may be the key point - I only want to see assigned config if it's part of the current bundle. Any other modules present on my site's file system, but part of a different bundle, don't matter here.

So, possibly, what we need to do is limit the file scanning to features modules that are in the current bundle.

nedjo’s picture

Status: Needs review » Postponed (maintainer needs more info)

Postponing pending clarification on the questions in #16, specifically:

Are the modules that provide the same configuration objects in different features bundles (see the documentation page on features bundles)? Would it therefore solve the issue if we limit the file scanning to features modules that are in the current bundle?

zipymonkey’s picture

I have not tried out the patch but I am seeing the same issue. I have 2 features in separate bundles. Only one is enabled but the configs are being imported from the disabled feature.

Limiting the scanning to the current bundle would be helpful... at least in my case.

vladimiraus’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community
  • Patched applied to to the latest stable version of features
  • BEFORE PATCH: Features scans and imports config from some (not all) Uninstalled features
  • AFTER PATCH: Features doesn't import config from Uninstalled features

@nedjo to answer question #17, for me they are in the same bundle: default.

vladimiraus’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new12.83 KB
new3.73 KB

I ran into an issue where exporting uninstalled feature (with drush in my case) would overwrite it relying on the current config (which is not available in regards to that particular feature config).
Patch and diff are attached.

The last submitted patch, 20: features-multisite-2975820-20.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

The last submitted patch, 20: features-multisite-2975820-20.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.