Problem/Motivation
During the development of a site, developers should almost always use the same custom bundle to export features related to that site. This means that every time they export a feature (at least between sessions) they have to make sure to manually select the correct bundle.
Steps to reproduce
- Create a new bundle and select it in the "Bundle" field on the features overview page (/admin/config/development/features).
- When you re-login and go to the features overview page then you should see that created bundle is still selected.
Proposed resolution
One option would be if the "default" bundle could be saved as a config value. Note that this is not the "default" bundle that's provided out of the box by Features, but rather the ability to set any bundle as the default bundle.
However, there are issues with that approach. We currently store the default bundle in a session variable. If we add a new default setting to features.settings, we have to map out the interaction between the session variable and the new setting. Also, we have to set the initial value to default (since, in Features itself, we can't count on any other value being present).
Alternatives:
- When a new features bundle is installed, set it as the current bundle in the session. Downside: this will work only for the user who installed the bundle.
- Move the current bundle out of the session and instead use a state setting. Downside: all users would have the same default bundle.
Instead:
- Use state (per the state API) in addition to the session to store the current bundle. First check session, then state, and if both are empty then fall back to default.
- When a new feature bundle is installed, set it in the state.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | features-current-bundle-2789001-17.patch | 8.47 KB | ohorbatiuk |
Issue fork features-2789001
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
nedjoComment #3
nedjoAgreed this is an issue worth addressing. Looked a bit at options and found it's more complex than it first appears. Sketched in some possibilities.
Comment #4
nedjoComment #5
nedjoComment #6
nedjoPatch with test.
Comment #8
nedjoComment #10
nedjoReverted the previous commit as it triggered #2948432: Circular reference detected for service "features.config_save_subscriber".
Setting back to active.
Comment #11
norman.lolHey hey, can you outline roughly what exactly caused this problem?
Comment #14
ohorbatiukUpdated patch from #6.
Comment #15
nedjo@chmez: thanks for working on this. Can you explain how this patch differs from the previous approach? Will the new approach avoid triggering the circular reference that was the reason we had to revert?
Moving to 5.0.x as no further work will be done on the 8.x branches.
Comment #16
ohorbatiukHi @nedjo. I can not apply the previous patch on the "8.x-3.x" branch so I've just fixed conflicts, used injected services, deleted unused code. You can see differences between these patches below:
Also, I can confirm that my patch can be applied to the "5.0.x" branch.
Comment #17
ohorbatiukUpdated patch from #14.