- 🇫🇷France louis-cuny
How to handle this issue without creating BC breaks/new major version?
Maybe something like:
On any export, export to the new splitted configuration(s) and delete the corresponding part from legacy config
On import, for each entity type, if we find data on splitted config, use this one, if not, try the legacy config fileWe need to make sure to handle entity types separatly.
Users may use structure_sync for all entity type but export only one time for some reason and wouldn't expect entities disapearingWe should then deprecate the usage of the old structure_sync.data config and plane to delete it in a next major version
~~~
Other possibility would be to work on a new major version where we simply ask to users to re-export everything after major version update
- 🇫🇮Finland heikkiy Oulu
+1 for this feature. We have encountered the issue several times now. It even doesn't necessarily involve several developers but a single developer might have hard time figuring out what the conflict with the structure data YAML file is.
We have used Fixed block content module in another project and it splits for example each block config into a separate file and we haven't had the same issue there.
I think it would make sense here also because each block, taxonomy and menu is a separate configuration in core also so you would have a linked structure file for it.