Created on 28 June 2025, 4 days ago

Problem/Motivation

This is a high-priority follow-up to ✨ Add a command-line utility to export content in YAML format Active , which lays the foundation for exporting default content in core.

In that issue, we added the ability to export a single entity. Its dependency information is collected, but dependencies are not automatically exported. In this issue, we should add the ability to export a content entity to disk, along with all of its dependencies (and any attachments, like files) in a coherent folder structure. Similar to what the Default Content module does in contrib.

Proposed resolution

Add a --with-dependencies|-W option to the content:export command. If this option is passed, the content entity and its dependencies are recursively exported to a directory on disk, which defaults to public://content (but can be specified with a --dir|-d option). File entities are exported along with the physical file they refer to, which is dumped next to the exported file entity (exactly the way Default Content does it).

API changes

Probably.

Data model changes

None expected.

Release notes snippet

TBD

✨ Feature request
Status

Postponed

Version

11.0 πŸ”₯

Component

default content 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
  • πŸ‡¦πŸ‡²Armenia murz Yerevan, Armenia

    To make it work well, we also need to allow configuring the depth of the dependencies, and the list of reference fields to skip from exporting, because without this can produce a huge amount of unnecessary entities and even circular redirects. As an example of how to resolve this issue, we can look at this implementation: ✨ Allow to partially export content Active

  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    Good point about the circular dependencies, we should ensure we specifically test that.

    I think allowing fields to opt out of being exported should be admin configurable and happen in a follow-up, as it might have some additional complexity best handled separately.

    As for dependency depth control β€” why? What would the use case be for such a thing?

  • πŸ‡¦πŸ‡²Armenia murz Yerevan, Armenia

    About the depth - let's imagine a "page" node which has a reference field "related_articles" with several articles, and each article has a field "related_pages" linked to some pages - by exporting this, we can get a pretty long nested structure, and even loops.

Production build 0.71.5 2024