- Issue created by @phenaproxima
- 🇺🇸United States phenaproxima Massachusetts
The implications of this issue are significant. I think we should do it, for sure -- if we do, it will allow us to remove a great deal of special processing from the
ContentExportNormalizer
we're adding in ✨ Add a command-line utility to export content in YAML format Active . - 🇺🇸United States phenaproxima Massachusetts
The more I think about this, the more I think we probably want to add a new top-level
exportable
key to field configuration entities (i.e.,field_config
andbase_field_override
). Having it as a setting of the field type plugin is more complex and is asking for backwards compatibility and update path headaches. Adding a new top-level key is straightforward. - 🇺🇸United States phenaproxima Massachusetts
More thoughts, which I shared with committers on Slack:
A few thoughts here, based on a point someone raised in a postponed follow-up — right now, ✨ Add a command-line utility to export content in YAML format Active includes some low-level but probably harmless hacks (like the
do not export
setting) to prevent certain properties/fields from being exported. I think that, in a follow-up — or really, probably a raft of follow-ups -- we might want to formalize the concept of “exportability” at the data layer level. Semantically, “exportable” could be similar to “internal” — it’s up to the calling code to decide what it means and what to do with it. But we might want to add aDataDefinitionInterface::isExportable()
method — not sure how disruptive this would be?