Problem
- Despite huge efforts and spending entire weeks with working almost full time on the configuration system, the Drupal core process fails, and we're not making any substantial process at all.
- We've tried to distill architectural changes into separate and isolated issues previously. But the isolation is inherently missing the big picture. People not only had a hard time to make sense of the isolated changes, but the individual change proposals itself were partially conflicting with each other.
- At the current pace of individual issues, we would be done with the required re-architecture work at the time of feature freeze. But there's a huge stack of other efforts and issues that are blocked by the re-architecture work.
Goal
- Replace the configuration system with a working implementation.
Notes
- This change combines the essential roadmap changes into a single.
- No random patches. Entire development happens exclusively in the CMI sandbox. The main branch is config-next-1626584-sun.
Combined issues
DONE: #1605324: Configuration system cleanup and rearchitecture
DONE: #1626398: Move the Configuration system to Dependency Injection
DONE: #1605236: Move synchronization methods from StorageInterface to DrupalConfig
#1624580: Research and implement a proper design for StorageDispatcher
DONE: #1447686: Allow importing and synchronizing configuration when files are updated
DONE: #1609760: hook_image_style_*() is not invoked for image styles upon Image module installation
DONE: #1609418: Configuration objects are not unique
DONE: #1605338: Implement pluggable storage for configuration system
DONE: #1605124: Configuration system performance
DONE: #1505090: Clean up all (non-default) configuration (files) when a module is uninstalled
DONE: #1608912: (Re-)adding keys to configuration breaks the intended goal of being able to diff files
@todos
Rename ConfigObject into just ConfigRename StorageManager to StorageDispatcher#30: Remove hook_config_import_validate() and _error().- FileStorage throws exceptions, while DatabaseStorage does not. Exceptions are not caught anywhere.
- Config objects need a better method of identifying whether any configuration data exists initially.
- Modules need a way to access the active store, whatever it is, without explicitly referencing DatabaseStorage.
@todos originally planned here, but deferred
- Configurable module thingies: Find a proper name. ;)
- Configurable module thingies: At minimum, introduce a consistent interface.
- Configurable module thingies: Consider to introduce a ConfigObjectBase that can be extended by all.
- Implement Drupal\image\Style object, make Image module API use it. Migrate image style rename/replacement style behavior.
Issues that won't be included here
#1624580: Research and implement a proper design for StorageDispatcher (#17 + #24 + #28)
#1605460: Implement dependencies and defer process for importing configuration
#1324618: Implement automated config saving for simple settings forms
#1552396: Convert vocabularies into configuration
Comment | File | Size | Author |
---|---|---|---|
#130 | config.next_.130.patch | 14.64 KB | sun |
#129 | config.next_.129.patch | 64.66 KB | sun |
#128 | config.next_.128.patch | 65.16 KB | sun |
#128 | interdiff.txt | 502 bytes | sun |
#123 | config.next_.123.patch | 65.32 KB | sun |
Comments
Comment #1
sun#1605324: Configuration system cleanup and rearchitecture including DI container.
Obviously, this code lives in a CMI sandbox branch and will only developed in there. Will update the issue summary.
Comment #1.0
sunUpdated issue summary.
Comment #2
sunAdding in #1447686: Allow importing and synchronizing configuration when files are updated in order to supply the first actual use-cases.
Introduces 1 test failure.
Not sure how to resolve the following — @Rob Loach to the rescue?
Comment #4
sunIncorporating #1505090: Clean up all (non-default) configuration (files) when a module is uninstalled
Includes fixes for the ill-informed test assumption that anything would write to files.
Comment #4.0
sunUpdated issue summary.
Comment #6
sunCleaned up exceptions.
Comment #8
sunAdded export operation, the natural counterpart to any import operation.
That is, to fix the import tests.
Comment #8.0
sunUpdated issue summary.
Comment #10
sunResolving #1608912: (Re-)adding keys to configuration breaks the intended goal of being able to diff files
Comment #10.0
sunUpdated issue summary.
Comment #12
gddThere are several of the roadmap changes that are controversial, and the roadmap as a whole has no widespread support as far as I can tell. These issues need to be discussed individually and patches done incrementally. I'm sorry you're frustrated but its not going to work this way.
Comment #13
sungetNamesWithPrefix() has to be aware of the storage controller configuration.
Comment #14
sunPeople can continue to discuss the individual changes in isolation.
There's little point in doing so, since the isolation is missing the big picture. Which, in turn, is the exact cause of the controversy in the first place.
This work already revealed a range of misconceptions stemming from individual issues. It will continue to do so.
Comment #16
sunNow getting to the actual core of architectural and systematic problems:
Added config_test module implementation of a "configurable thingie".
Bare essential module code only. Pretty much based on @merlinofchaos' comments elsewhere on how he'd like to use configuration objects/data for configurable thingies.
Comment #17
sunComment #19
sunAdded basic functional tests for a configurable thingie, including essential basics for renaming a configurable thingie.
Comment #20
chx CreditAttribution: chx commented<sarcasm>I am glad you read #1560060-18: [meta] Configuration system roadmap and architecture clean-up and acted accordingly.</sarcasm>.
Comment #21
sunFixed combined expectations on delete behavior.
Typical issue that would take entire weeks to resolve through separate/isolated issues.
Comment #23
sunImplemented hook_config_import() for configurable test thingies.
Tests are incomplete. Got distracted by researching why only the 'delete' import operation fails. Still suspect a typo somewhere.
Comment #24
chx CreditAttribution: chx commented#17 what about injecting the active storage (as it happens now) and use the FileStorage directly to import/export/sync. What stops us from doing this? We would not need
$this->setParameter('config.storage.info'
which lacks the information about what is active storage and what is file storage, we could just do $this->setParameter('config.storage.active and $this->setParameter('config.storage.file?Comment #26
webchickWhat the what? I really don't understand why this was done, at all, let alone deliberately against Greg's request/recommendation. We need a real, actual issue summary here. Tagging.
Comment #27
webchickAlso, let's not forget we're a core development team here. Not an army of one. Especially an army of one who tears down others' work in the process of improving it. "Come for the software, stay for the community" isn't just something we say to feel good about ourselves. It's the basic underlying fundamentals of our community. http://drupal.org/dcoc
Comment #27.0
webchickUpdated issue summary.
Comment #28
sun@chx: That sounds like a good idea to me. At least worth to explore. I'm a bit worried about how the import/export code would look as a result of doing that, but alas, that's the exact cause and reason for combining the changes. ;) It also means we'd lock the architecture into two stores — effectively turning the $conf override into a permanent "hack" that isn't considered as a storage.
Since that is a relatively huge change in terms of architectural design, I will fork into a config-next-nomanager-1626584-[sun] branch, unless someone beats me to it.
Comment #29
sunBut first:
- Fixed instantiation of ConfigObjects via new ConfigFactory.
- Fixed import does not catch storage exceptions.
Comment #30
sunComment #30.0
sunUpdated issue summary.
Comment #31
sunWent ahead and implemented #30. This change can be reverted, if there's disagreement.
Also updated the issue summary with @todos extracted from the code and issue comments.
Comment #31.0
sunUpdated issue summary.
Comment #32
sunFixed straw unconditional loading of config.inc in bootstrap.inc.
Comment #33
sun- Completed ConfigImportTest for dynamic configuration.
- Fixed bogus $op conditions in hook_config_import() implementations.
Comment #34
sunAdded ConfigObject "cache" to ConfigFactory, including elaborative notes for further research and performance profiling.
(The benchmark script that was used can be found here.)
Comment #36
alexpottI'm not sure that we need to cache every config object for each name. This patch suggests an alternative approach that only caches one configObject that might be more memory efficient.
My work is tracked in config-next-1626584-alexpott
Comment #38
alexpottThe caching of the config object introduces issues for config_test_load(). Fixed by cloning the config object the loader retrieves.
Comment #39
alexpottComment #40
cosmicdreams CreditAttribution: cosmicdreams commentedsun:
Can you please update the summary with reasons why you think the current architecture needs to be replaced, with an emphasis on how your revision corrects those problems?
I think I've read in other issues an explanation of your reasoning, but don't want to put words in your mouth.
Comment #41
sun#38 skips the DI container a bit too aggressively and the clone is basically equally "ugly" as the previous clone that was directly in config() since #16 and following. I've therefore reverted the premature caching of ConfigObjects in ConfigFactory entirely, but retained the comments and @todos. We still want and need to figure this out in order to fix the performance problem of the configuration system, but it makes more sense to re-think the architecture first. If the removal of StorageManager will work out, then it's possible that we might not need the ConfigFactory in the first place anymore. So let's defer that to later.
Comment #43
sunToo many changes in HEAD, so had to merge (and move config-next-base).
Comment #44
RobLoachYeah, it looks like we're not using the "config" service anywhere.
Hmmm, ConfigFactory is the only place that uses 'config.object', which is just a wrapper around the Container, which seems interesting. Instead of passing the Container into the ConfigFactory, the ConfigFactory's constructor should take the ConfigObject class name and the ConfigManager instance. We want to send objects their dependencies to reduce our dependency on refering to the container all the time.
Then we don't have to refer to the container from ->get() as we already have all the dependencies we need. Should I post a patch in one of your sandboxes? To pass them into the constructor during instantiation, you'd refer to the parameters during the ->register() call.
Comment #45
sunb175f35 Removed ContainerBuilder dependency from ConfigFactory.
183e987 Renamed ConfigObject into ConfigContainer.
Comment #47
alexpottThe patch no longer applies because #1589174: Configuration upgrade path is broken has landed... and this mega patch also contains it :)
Comment #48
sunMerged in HEAD.
Comment #49
sunRenamed ConfigContainer into Config due to way too many confusion and mistaking it as DI container within a single day of discussions.
Comment #51
Jose Reyero CreditAttribution: Jose Reyero commentedRelated patch, that adds Plugins and Storage realms on top of this, #1646580: Implement Config Events and Listeners, and storage realms for localized configuration
Comment #52
Jose Reyero CreditAttribution: Jose Reyero commentedThe patch in #49 has some issue with the file name that contains the class, renamed DrupalConfig.php to Config.php
Comment #53
Jose Reyero CreditAttribution: Jose Reyero commentedThis is a patch that tries to simplify the previous one and also changes StorageManager so it can be really used for import / export, which also allows us to move some of these related functions into the class.
Some bits of the patch:
- Really simplified dependency injection:
- Reworked constructors so there's more encapsulation and we save lines of code. Example of export operation:
- Simplified config_import() too, though I'd really get rid of that hooks for this patch and let them for later...
- Simplified Config::read() and Config::write(), we really don't need complex logic to get hold of the storage interface.
Comment #54
gddAt Drupal Dev Days in Barcelona, it was discussed that while we need separate issues and patches in order to isolate changes into reviewable chunks, there is also value in maintaining a single branch / ongoing patch that contains the big picture of how the various rearchitecture efforts are interacting. However, we already have a place for that, the original roadmap issue at #1560060: [meta] Configuration system roadmap and architecture clean-up. Therefore this issue is being closed, and further overarching patches will go into the roadmap issue.
Comment #54.0
gddUpdated issue summary.
Comment #55
sunHm. Actually, I think it would be beneficial to keep the meta issue about high-level discussions. If we start to throw patches in there in the same way as here, then that will pretty much break and hi-jack the discussion thread.
Slowly but certainly preparing for extracting the basic architectural changes into #1605324: Configuration system cleanup and rearchitecture... In this patch:
ae96279 Simplified service registration in ContainerBuilder.
d139080 Fixed fatal error in early Drush bootstrap.
866235b Renamed StorageManager into StorageDispatcher.
Comment #55.0
sunUpdated issue summary.
Comment #57
sunNow, after cleaning up docs and stuff, the next best major @todo in the issue summary, the consistent handling of errors, exceptions, and edge-cases in all storage controllers, was anything but trivial, and required to (finally) add dedicated/isolated tests for storage controller CRUD operations.
This @todo was originally triggered by the import and export operation changes that are combined in this patch, since those are accessing the storage controllers in unusual ways.
Adding these tests also revealed that getNamesWithPrefix() is a very odd method name on the storage controllers. The $prefix argument is optional, and one of the primary use-cases of that method is to actually list all config object names in the storage (bin). Limiting the list to a certain prefix only is a special case, not the common case. I've therefore renamed the method to just listAll(). [list() is not possible, since it's a reserved keyword/language construct in PHP.]
In turn, that rename results in storage controller method functionality that actually resembles Create, Read, Update, Delete, and List.
So, in this patch:
ec3296e Fixed missing and improper phpDoc and unnecessary imports.
a7c91f6 Relocated read/write/delete methods in FileStorage to match interface.
cde4e87 Fixed stale StorageDispatcher service name in config_import_invoke_sync_hooks().
124cfe1 Fixed bogus thrown exceptions and documented storage controller return values and which exceptions and errors are actually thrown.
1e61723 Renamed getNamesWithPrefix() into listAll().
65723d1 Added unit tests for storage controller CRUD operations.
Note that both storage controllers should actually throw (various) exceptions on different edge-cases, but I wasn't able to trigger those exceptions in the added tests (yet). Although this is technically incomplete, I do not plan to complete/fix that test coverage right now, as it is very important to get the basic refactoring out of the way.
Comment #59
sunTotally forgot to mention that the new tests assert expectations, which are not met by the storage controllers yet. ;)
eba99fb Fixed functional code for expectations on invalid storage controller options.
Comment #60
sun172f09d Fixed stale references to "container" and unnecessary use statements.
(Discovered during extraction for #1605324: Configuration system cleanup and rearchitecture)
Comment #61
sunPlain re-roll for #1605324: Configuration system cleanup and rearchitecture
As visible, most of the remaining changes are about #1447686: Allow importing and synchronizing configuration when files are updated.
Before moving ahead with that import mechanism though, we first need to find a common denominator for #1609760: hook_image_style_*() is not invoked for image styles upon Image module installation
Comment #62
sund'oh.
Comment #63
sune4a2c10 Fixed module API hooks for thingies are not invoked on module installation.
(#1609760: hook_image_style_*() is not invoked for image styles upon Image module installation)
Comment #65
sunLOL! Finally figured out what the problem of #64 is ;)
"Obviously" the import mechanism involves a full synchronization, so for each installed module, a full diff is performed, adding the new config of the installed module, but deleting any and all config that existed before :-D Nice! :)
Also, FWIW, the very first debug() within default config install function shows a "change" for system.cron, which looks highly suspicious to me:
Comment #66
sun7790497 Clarified namespace/owner callback architecture by renaming functions and cleaning up docs.
9f06a38 Introducing Config::isNew() and NullStorage.
Comment #68
sun6ef6442 Implemented Config::isNew() in module APIs.
4b660b8 Fixed improper handling of FALSE return value of storage controllers. Added test coverage for isNew().
Comment #70
sun301e5ea Fixed fatal error in image_style_load().
565124f Fixed stale references to DrupalConfig.
a0bc28e Moved config_test module into tests subdirectory.
Comment #71
sune20b52b Copied ConfigTest into Drupal\Core\ConfigThingie\ConfigThingie.
7f20970 Added generic ConfigThingie with abstract base class and interface.
6b92dac Renamed ConfigThingie::load() into ::setConfig(). Added type-hinting, docs, and cleaned up implementation.
Comment #72
sun4aca5c4 Removed $op from MODULE_config_import() callback.
24b3b35 Added docs for NullStorage.
Comment #74
sunMerged latest 8.x into config-next.
Comment #76
sun9436165 Removed obsolete sync hook invocation test.
e3c1dda Removed base class specific methods from ConfigThingieInterface.
Comment #77
sunIncorporating latest changes from
#1447686: Allow importing and synchronizing configuration when files are updated
#1668820: Concept, base class, and interface for Configurables (e.g., node types, image styles, vocabularies, views, etc)
Comment #78
sun756dd4d Added tests for import/export UI.
Comment #79
sun9dabce4 Fixed config import screen deletes all configuration initially (stop-gap UX fix).
Comment #80
sun89dd92d Updated ConfigImportUITest::testImportLock() for new empty source storage behavior.
2c80423 Added assertions for new empty source storage UI behavior.
Comment #81
sunRe-rolled against HEAD.
Comment #82
sunIncluding #1671080: Remove StorageDispatcher to simplify configuration system
Comment #83
sunI'm afraid, but I see no other way to get back to this issue and make it real again. There are conflicting change proposals in other issues.
We've decided to remove the StorageDispatcher. And replace its functionality with a new MultiStorage controller that simply wraps multiple other storage controllers to perform CRUD operations in multiple storages instead of one.
The concrete use-case for the MultiStorage controller is the idea of (re-)enabling "concurrent" (dispatched) writes/deletes to both the DatabaseStorage and FileStorage. Developers should be able to enable/configure that behavior; e.g., when working on local development sites on which all potential configuration changes will be exported anyway in the end, so they can be staged "upstream".
As such, the MultiStorage controller is suitable as the default active store on a development site. But not on a site that is supposed to import configuration. That is, because writing to both DatabaseStorage and FileStorage inherently conflicts with the idea of having differences between current and exported configuration. The moment you write, you eliminate any possible differences.
Furthermore, all hell breaks lose if you write to the FileStorage during an import.
Nevertheless, we want the active storage to be pluggable. This means that it is defined as a service on the Container and all code only ever refers to the service definition, never to e.g. DatabaseStorage directly. The service definition essentially enables developers to use the MultiStorage controller instead of the DatabaseStorage controller.
Making that service definition swappable is going to get a bit tricky, since it essentially is the lowest of low level configuration; i.e., configuration for the configuration system itself. We usually use global variables in settings.php for that kind of stuff, but I can already hear people screaming... ;) A potential alternative to that would be a single settings.yml configuration file, which would require us to always instantiate the FileStorage controller in order to load it on every request. That, with the potential goal of making these lowest low level settings configurable from the UI.
Anyway, the critical part is that we most likely need to hard-code a special condition for the MultiStorage controller into the config import mechanism, so as to deny execution, if it is configured as the active store.
The compatibility of all these changes has to be verified first. This investigation essentially blocks all the other issues, because not even I would have any idea where we're architecturally heading with the config system otherwise. Hence, bumping to critical.
Thus, kick-starting:
619f236 Added MultiStorage controller to enable "concurrent" (dispatched) writes to DatabaseStorage and FileStorage.
Comment #84
sunConfigurable thingies are still vaporware at this point, so we don't have interdependencies yet. It is going to get hairy to write a test which essentially confirms that the MultiStorage does break the config import mechanism. I will try to come up with something very hacky, but focused on detecting that problem.
Otherwise, this seems to orchestrate better than I had imagined - even though the overall changes are quite invasive so far already;
1d4c486 Hardened ConfigImportTest to take MultiStorage into account.
ffdf235 Moved ::exists() into StorageInterface.
3048ca1 Replaced all direct references to DatabaseStorage with config.storage service.
9bd8c71 Fixed module API hooks for config objects are not invoked on module uninstallation.
Didn't run all tests. Let's see what the testbot thinks.
Comment #86
sun58b0cb2 Fixed EnableDisableTest failures.
6ee9bfe Fixed bogus config storage service retrieval in config UI callbacks.
Comment #87
catchNot me. If it's good enough for the database and cache, it's good enough for CMI. If we eventually find a better way to do things that performs well that's fine but that can be its own issue.
Comment #88
gddI completely agree with catch on that one.
Comment #89
webchickDitto.
Comment #90
sunUntil we've figured this out, there are some smaller issues that really could use your attention in the meantime:
#1701014: Validate config object names
#1671198: Merge $conf overrides only once per instantiated Config object, and move initial setName() into Config constructor
Comment #91
sunComment #92
sun27b5566 Added CachedFileStorage controller; using files as canonical storage and another "active store" as cache.
Comment #94
sunJust an investigation based on wild ideas and discussions with @beejeebus ;)
3eb34fb Added CacheStorage to leverage existing Cache subsystem for file storage cache.
Comment #96
alexpottI added a cache storage layer in #1605124: Configuration system performance (really old version of config alert!). It worked great and one of the obvious benefits it that config will then be able to use memcache / redis etc... with no extra work.
The one issue of the approach are the chicken/egg situations in early bootstrap, early install, and update d7 to d8.
Comment #97
sunMerged HEAD.
Comment #99
sunNow... an essential change to verify and enable my resolution proposal for #1703168: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs
e415d18 Removed obsolete todos.
c4e9013 Introducing config.state to enable CachedFileStorage and configuration staging to work as intended.
Comment #101
sun003226d Fixed SearchExcerptTest cannot be a unit test.
Comment #103
suncd64db5 Removed all Configurable thingie/entity changes.
Architectural design and implementation for Configurables will continue in
#1668820: Concept, base class, and interface for Configurables (e.g., node types, image styles, vocabularies, views, etc)
However, thus far, those changes did not appear to be relevant for this combined patch (as well as spin-off branches + extracted patches), which apparently is in line with that issue's summary, which already states that Configurables are not part of the configuration system. Nevertheless, it was good to have them in the mainline until now.
Comment #105
sunAlrighty. Some massive changes to incorporate latest directions from #1703168: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs
:)
Added separate config/active and config/import directories.
Removed obsolete MultiStorage.
Fixed Container of parent site executing a test is leaking into tests.
Fixed ConfigImportTest hard-codes bogus configuration storage controllers.
Clarified variables and documentation for CachedFileStorage and CacheStorage.
Fixed bogus variable names in ConfigImportTest.
Added proper 'config' cache bin.
Removed obsolete 'config' database table.
Updated ConfigImportUITest for latest core changes.
Fixed CacheStorage can return bogus config object data.
Removed orphan/obsolete config_test.delete default config object.
Comment #107
sunAhem... so this turned out to be quite the challenge... ;)
Configuration is used and required all over the place in the installer already.
The fact that we're currently able to install Drupal at all is apparently caused by a full stack of "coincidences" and special cases that have been implanted into various subsystems in order to be compatible with the incomplete installer environment. Most of them kicked in, because they assume that the installer wants to talk to a non-functional database. So when switching to files, none of them apply anymore.
Fixed Cache\DatabaseBackend depends on procedural functions in includes/database.inc; and ::checksumTags() throws fatal error if database is not available.
Fixed Drupal installer cannot be fully tested in a separate sub/multi-site.
Fixed theme_task_list() does not use installer-compatible get_t().
Added InstallStorage to resolve fatal errors and misbehaviors during installation due to missing config directory.
Don't worry... I'll create separate issues for all the non-config stuff that had to be fixed here. (I'll edit this comment to inject the #issues later)
Comment #109
sunFixed Drupal\config\Tests\Storage\DatabaseStorageTest (technically obsolete though).
Fixed Drupal\config\Tests\ConfigFileContentTest hard-codes DatabaseStorage.
Fixed UpgradePathTestBase::performUpgrade() does not always load all new modules after upgrade.
Fixed {cache_config} table is not created when upgrading from D7.
Comment #111
sunHere's the list of spin-offs:
#1730774: Untangle Cache\DatabaseBackend from procedural database.inc functions to make it available in early bootstrap
#1730770: Drupal installer cannot be fully tested in a separate sub/multi-site
#1730760: theme_task_list() does not use installer-compatible get_t()
#1730754: UpgradePathTestBase::performUpgrade() does not always load all new modules after upgrade
Comment #112
sunFixed ConfigCRUDTest hard-codes DatabaseStorage.
Comment #113
sunMerged in HEAD.
Only remaining blocker is: #1730774: Untangle Cache\DatabaseBackend from procedural database.inc functions to make it available in early bootstrap
Comment #115
sunProperly merged in HEAD and latest changes from #1741804: Implement a config import/staging directory, which caused quite some "havoc"...
Merged config-directories branch.
Fixed bogus t() in theme_task_list().
Added new StorageInterface::rename() methods to new config storage controllers.
Fixed watchdog() triggers fatal error in Drupal installer.
Updated for CACHE_PERMANENT constant moved into CacheBackendInterface.
Fixed merge conflicts.
Comment #117
sunFixed public StorableBase::$isCurrentRevision property leaks into config objects.
Fixed ConfigImportTest and ConfigImportUITest for default properties of dynamic ConfigTest entities.
Comment #119
sunMerged in latest HEAD.
Still contains "config.state" as a service name. I hope we can figure out a proper/final name in #1703168: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs ASAP.
Comment #121
sunMerged in HEAD.
Will try to finalize + extract this patch today.
Comment #123
sunFixed HookBootExitTest fails due to added module_load_all() check in watchdog().
Renamed config.storage to config.storage.active, and config.state into config.storage.staging.
Fixed phpDoc, variable names, and code comments.
Comment #125
sunHm. I'm not able to reproduce that Drupal installation error (tested installation in a subdirectory).
Comment #126
sun#123: config.next_.123.patch queued for re-testing.
Comment #128
sunFixed PHP warning "The use statement with non-compound name 'Exception' has no effect."
Comment #129
sunEssential changes have been extracted into #1702080: Introduce canonical FileStorage + (regular) cache
However, test failures over there. If those are true, then this merge/re-roll should fail as well.
Comment #130
sun#1702080: Introduce canonical FileStorage + (regular) cache landed, which means that the main architectural changes are done.
Attached patch shows the remnants of the config-next branch.
Comment #131
sunThe remaining changes will be dealt with in:
1) phpDoc fix for FileStorage: #1702080: Introduce canonical FileStorage + (regular) cache
2) Consider using config import mechanism for uninstalling module config: #1765936: Invoke ConfigStorageController::delete on module uninstall and add tests
3) Configuration module UI: #1697256: Create a UI for importing new configuration
4) And also: #1760786: Move entity system "back" into a Drupal\Core component
Comment #132.0
(not verified) CreditAttribution: commentedUpdated issue summary.