Store UUID for exportability

From my experience, config for this module is exportable. I know this issue is super old, but do you have any more info to give?

Hmm. I'm trying to see what I'm missing here. Some more info would be great.

This module provides no config. It only attaches itself to blocks and becomes part of the block config. Because of that I don't see the need for default config or Schema. I can do a bit of research about other conditions in core etc though..

Maybe you can provide a basic patch or some more details about what you expect the module to do, then I can implement them if need be. Otherwise I'll close this for now, since everything seems to be working around the exports in my opinion.

Wow incredible. Thanks heaps. That was a lot more than I was expecting. This is going to conflict with some other patches I'll be committing this week, so I'll reroll on the latest dev when I'm committed those. Thanks again for the quality work!

I agree that matching terms by UUID, and exporting that instead of tid, is a sensible improvement here. The issue arises when a term is loaded from Default Content and the IDs generated from Default Content are not consistent (while UUIDs from Default Content are).

The patch does some cleanup, but does not appear to replace exporting by tid with exporting by UUID? Am I missing a fine point of config export?

Setting NW since it would now need to target 2.x.

For Sector sites, this will also relate to #3215735: Convert default content to YAML format.

Please review:

• stores UUID in config
• adds config schema
• adds update path
• fixes coding standards violations in plugin

Patch from #6 is not applicable anymore so no interdiff.

Hoping to get this in with the D10 updated. Will do some further testing before tagging a new release.

This should also give a more solid fix to errors with deleted terms as those should be silently dropped by loading via UUID.