[PP-1] Allow fields to be marked as non-exportable

Created on 29 June 2025, 6 days ago

Problem/Motivation

Add a command-line utility to export content in YAML format Active adds the ability to export entities in YAML format. By default, all non-internal fields and properties are included in the export.

In #3532951-3: [PP-1] Exporting content should also support exporting the content's dependencies to a folder structure on disk , @murz pointed out that we might want to make it possible to exclude certain fields from being exported. That seems legitimate, and should be configurable.

Proposed resolution

Alter \Drupal\serialization\Normalizer\ContentEntityNormalizer::normalize() to check field access for operations other than view. It should probably accept a $context['operation'] parameter, which defaults to view, but ContentExportNormalizer should pass export as the operation. This will give fields the ability to decide, through the regular field access system, if they should be exported or not.

Meanwhile, add an exportable setting to all fields types (in \Drupal\Core\Field\FieldItemBase::defaultFieldSettings() and in the corresponding field.field_settings.* config schema type). It should default to TRUE.

User interface changes

None in this issue; this just adds API-level support.

Introduced terminology

Probably none.

API changes

Yes; all fields will get a new setting.

Data model changes

Yes; all fields will support a new setting.

Release notes snippet

TBD

Feature request
Status

Active

Version

11.0 🔥

Component

field system

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @phenaproxima
  • 🇺🇸United States phenaproxima Massachusetts

    Postponed on the export command.

  • 🇺🇸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 and base_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 a DataDefinitionInterface::isExportable() method — not sure how disruptive this would be?

Production build 0.71.5 2024