Problem/Motivation
When we uninstall a module we list which configuration entities will be "affected" by the uninstallation. Configuration entities will either be deleted or fixed (through implementations of ConfigEntityInterface::onDependencyRemoval()
. Previously it was not possible to work out what would happen to each configuration entity but #2361775: Third party settings dependencies cause config entity deletion has opened up the possibility of that we can. Also #2416409: Delete dependent config entities that don't implement onDependencyRemoval() when a config entity is deleted is looking to implement dependency fixing / deletion on all config entity deletes so telling the user exactly what is going to happen in more important.
Proposed resolution
Add new functionality to the ConfigManager and ConfigDependencyManager to work out what is going to happen when a specified dependency (or set of dependencies in the case of multiple modules) is going to be removed.
Remaining tasks
Write patch
Review
Commit
User interface changes
The list of affected configuration on the module uninstall confirm screen will change.
API changes
Only additions.
Comment | File | Size | Author |
---|---|---|---|
#16 | 2420107.16.patch | 31.46 KB | alexpott |
#16 | 14-16-interdiff.txt | 1.13 KB | alexpott |
#14 | 2420107.14.patch | 30.92 KB | alexpott |
#14 | 9-14-interdiff.txt | 4.5 KB | alexpott |
#9 | 2420107.9.patch | 30.9 KB | alexpott |
Comments
Comment #1
alexpottHere's a patch that implements the functionality. Now need to use it and write tests.
Comment #2
alexpottComment #3
Wim LeersThis will allow for significantly enhanced usability/DX. The code looks beautiful and promising. :)
Should have a trailing comma.
That sounds beautiful :)
The body of the loop is a bit hard to follow for those less familiar with details of CMI though (at least for me). A few more high-level comments at for the three if-branches would be helpful.
I don't think the empty check is necessary, the while condition takes care of that?
Comment #4
alexpottSince this is blocking a critical and I would argue it is a critical in itself. Just listing which entities is affected on the module uninstall confirm form is not that helpful for users.
Comment #5
alexpottI've rewritten the config uninstaller and module list confirm form to use the new code and in doing that brought in necessary changes to the original code in #1 which makes an interdiff irrelevant.
Test coverage of both module uninstall and config uninstall has been expanded to cover as many of the possibilities I can think of. Additional test coverage has been added to ensure that methods work with content dependencies too even though it is unlikely the core will use the methods to do this.
Comment #7
alexpottFix the delete. This is due to dependency ordering that was working in the config uninstaller - that's why it is good that everything - config uninstall and config entity delete will use the same code path.
Comment #9
alexpottYep the order is significant - fixed my tests, doh :)
The patch also fixes some documentation around checking content dependencies.
Comment #10
cilefen CreditAttribution: cilefen commented+1 for the function name.
Comment #11
alexpott@cilefen yeah I just said what is does - but would be happy to have a better suggestion because it is long winded. And I didn't want to think that much about naming when the real mind-bending stuff is how to manage a dependency graph and changing it.
Comment #12
cilefen CreditAttribution: cilefen commented@alexpott I wasn't judging! I agree with everything you said.
Comment #13
Wim Leers#4:
+1
#7:
HURRAY!#12: I think the only way to shorten the name is to have an intermediate value object. Which is probably not justified here.
I can basically only find nitpicks:
s/will modified/will be modified/
"in the returned order" ?
Nit: Typehint to
array
?"deletes" or "deletions"?
Comment #14
alexpottFixed everything in #13.
Comment #15
Wim LeersJust one tiny remaining nit that can be fixed on commit: the #14.3 typehint is added to the code, but missing in the docs.
Comment #16
alexpottFixing #15 - thanks.
Comment #17
catchJust fixed missing capital letter here on commit.
Fantastic patch. Committed/pushed to 8.0.x, thanks!