Problem/Motivation

#3532694: Add a command-line utility to export content in YAML format 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: Support exporting content and its 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

Issue fork drupal-3533005

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Status: Active » Postponed

Postponed on the export command.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

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 #3532694: Add a command-line utility to export content in YAML format.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

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.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

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, #3532694: Add a command-line utility to export content in YAML format 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?

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Needs issue rescope

#3532694: Add a command-line utility to export content in YAML format implemented a mechanism for doing this dynamically, so this maybe needs a rescope to decide if we even want to implement a field-level "exportable" setting.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Title: [PP-1] Allow fields to be marked as non-exportable » Allow fields to be marked as non-exportable
Status: Postponed » Active

Core blocker is in.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.