Closed (duplicate)
Project:
Drupal core
Version:
8.9.x-dev
Component:
configuration system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
15 Aug 2018 at 09:52 UTC
Updated:
22 Apr 2020 at 19:47 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
tstoecklerComment #3
bircherAdding the CMI 2.0 issue tag.
Comment #4
tstoecklerStarting working on this for a bit, nothing to share yet, but wouldn't make sense for anyone to work on this. In case anyone else is motivated to push this forward just let me know here and I will upload a work-in-progress patch.
Comment #5
bircherIf you are going to use a
StorageComparerfor this consider reviewing the following issue:#2993271: Remove unused ConfigManager dependency in StorageComparer
Comment #6
bircherOh! I didn't mean to un-assign you! But there was nothing I could do.
Comment #7
tstoecklerAhh, that's a nice catch!
Here's an initial patch. It is just step 2. from the issue summary, so it provides an archive storage that could then be used together with a configuration exporter by the Config UI. Awesomely,
ConfigStorageTestBaseexists, so I could actually fix a huge number of bugs and finally verify that it actually works correctly, without ever hooking it up into runtime code. Unfortunately, it's reeeally rough right now, not just around the edges. In particular::delete()is pretty bad, and the fact that we can't do a proper update, but call out to::delete()in::write()is not good. But it does work, so it should allow the rest of the work with the exporter and hooking it all up in the UI to proceed.In theory, adding the
ArchiveStoragecould also be split into a separate issue, but not sure what maintainers have to say about that.So now that that step is done, I think I no longer need to be assigned here. I will try to put some time towards the remaining steps, but this should be a (ugly, but) solid base for anyone to continue work here.
In more concrete terms: I guess the next step would be copying the exporter from #2991683: Move configuration transformation API in \Drupal\Core\Config namespace and then trying to make it work in the UI.
Comment #8
tstoecklerAlright, this seems to be all that's needed. And it works for me, as well. Let's see what the bot says.
Comment #9
bircheryea this is not great. But unfortunately with the ArchiveTar there is not much we can do.
Maybe we can postpone the ArchiveStorage and implement the exporter without it.
this whole code would be in the first instance just
StorageCopier::copyConfig()#3016429: Add a config storage copy utility trait and fix ConfigManager::createSnapshot, but it is where the transformer api will be called.I approve of this very much!
This is where I think we could improve things already even without the archive storage but by using the active storage instead of the config manager. This would allow us to simply call the transformer first.
so the code here would be:
This way we could replace
$storage = $this->activeStorage;with$storage = $this->storageTransformer->transformExport('config.storage.sync');(or'config.storage.tarball'etc..)Comment #12
vinay15Comment #13
vinay15Rerolled the patch in #8 and removed the ArchiveStorage and ArchiveStorageTest files as per point 4 in #9.
Also, I tried
executing in devel and the configuration was exported successfully.
Comment #14
hardik_patel_12 commentedAs @bircher mentioned in point #4 that replace ,
this whole code would be replaced with static method replaceStorageContents of StorageCopyTrait.
As this export() function is exporting all configuration and then put it in an archive, but what if any contrib modules wishing to export only some set of configuration for example (system.site and user.settings). In that case we can receive set of configuration which needs to be export in export() function as argument as shown in patch.
So now we can export all configuration as well as particular set of configuration or single configuration and then put it in an archive.
Comment #15
bircherI think we can close this as a duplicate of #3036193: Add ExportStorage to allow config export in third party tools
While it is not strictly the same, the exporter here would be quite trivial:
with the service definition:
See the change notice https://www.drupal.org/node/3037022
I am not sure what a service would be used for other than just calling it from a cli command or maybe in the future from a button in the UI, but then I think we can do that there. #14 suggests that more features would be expected so I think we should open a new issue and scope out the requirements first. The requirements we had planned in this issue have been met.