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
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | features-multisite-2975820-12-20.diff | 3.73 KB | vladimiraus |
| #20 | features-multisite-2975820-20.patch | 12.83 KB | vladimiraus |
| #12 | feature_multisite.patch | 11.52 KB | noita |
Comments
Comment #2
noita commentedComment #3
noita commentedComment #4
noita commentedHi Guys,
I have create a patch with all change that I have test on my instance.
This patch change some element :
I hope that's a good solution ...
And hope to ave your return quickly :)
PS: Sry for my english
Comment #5
noita commentedI just change hard coded number by the constant.
Comment #6
noita commentedAnyone to respond to this problem ? ( Use this patch in production and want to have your return about that )
Comment #7
RAFA3L commentedI think you can't set the same view into multiple features
Comment #8
noita commentedYou 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.
Comment #9
noita commentedHi,
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
Comment #10
botanic_spark commentedI 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.
Comment #11
botanic_spark commentedIs there a reason why we are forcing this? If set to TRUE, it gives errors when reverting features.
Comment #12
noita commentedHi 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:
After that use "composer update" to refresh the module with the patch.
Comment #13
weynhamzNice 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.
Comment #14
jasonawantChanging 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.
Comment #15
nedjoThanks 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:
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.
Comment #16
nedjoReturning to the original report:
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:
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.
Comment #17
nedjoPostponing 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?
Comment #18
zipymonkey commentedI 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.
Comment #19
vladimiraus@nedjo to answer question #17, for me they are in the same bundle: default.
Comment #20
vladimirausI 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.