Support default content entities

More discussions over at #79582: Add example content to the experimental out-of-the-box demo install profile

Note https://github.com/larowlan/default_content

The YAML Content module supports some of this approach as well.

https://www.drupal.org/project/yaml_content

The automatic installation of content with a module isn't implemented, but this could easily be added using available services through the install hook.

http://drupal.org/project/default_content

The ability to create default content as part of installing things in Drupal has become an aim for #3274999: Distributions and Recipes initiative overview and roadmap therefore I think we should make this issue a part of it.

Contrib has a pretty mature solution - the default content module but @larowlan wrote https://www.previousnext.com.au/blog/we-could-add-default-content-drupal... a while back about the issues.

I think we need to update the issue summary with steps we need to take to bring something like it into core. I feel the supporting the 2.x yaml file format would be a big boon as it would allow people to move from contrib to core with little change.

Demo umami using migrations for initial content

Looks it's shortest route to reuse it

Also we using https://www.drupal.org/project/migrate_generator on custom projects

@andypost demo umami is not using migrate as far as I know. See \Drupal\demo_umami_content\InstallHelper - it's custom all the way down.

As well as Default Content, some other similar modules in contrib (at varying levels of stability/completeness) are:

• Migrate Default Content
• YAML Content

I also wrote a PoC module which exports the specified content into migrations: Entity Migrate Export

Drupal 8 has support for default config entities, but not for default content entities.

It could be useful to identify code that is potentially reusable

Quick search on some prior art for default config

tests for "default config"

• https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/tests/Drupal...
• https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/tests/Drupal...
• https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/tests/Drupal...

default config storage: DEFAULT_COLLECTION constant in the storage interface, used by the tests, seems to be relevant

• defined here: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
• example of usage: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...

I would prefer a migrate based approach for default content.

There seems to be a general consensus in this issue that we ought to base a solution on a relevant core API. The problem is, which one? We have at least three different solutions in core for the general problem of defining and installing/creating/importing an entity with its associated properties:

• Config entity handling in ConfigInstaller and ConfigImporter.
• The migrate API.
• Serialization + REST.

Choosing between them is not straightforward. What seems key is to first make sure we're clear on the spec.

There are at least three related use cases: importing, updating, and staging content. If all three are valid, we should build an API that, even if it doesn't immediately support all three, could do so in future.

Related:

• #2248369: [meta] Deploying configuration that depends on content
• #2756331: Custom blocks cannot be properly exported and imported
• #788708: Content Staging
• #2937376: Document what the REST and Serialization modules are for: decoupled Drupal sites or content syncing

@alexpott
I think that most of the issues that are mentioned in the Blog post you attached, have already been tackled one way or another in the default_content module.

@nedjo
I would not count REST and Migration as valid ways to have 'default' content.

In my understanding.. 'default' means demo content or content that you want to have tracked during development (Some basic pages / terms etc). I don't think that the default content aspect of drupal should handle massive numbers of imported entities. That is handled by migration :).

This is a Roadmap ToDo Issue for Phase 1 of the Distributions and Recipes Initiative. Besides updating the Issue Summary, are there some child issues that should be created for this issue?
I am taking a first pass at some minor updates to the summary.

Reviewing a related docs https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/do..., I am creating an issue to remove "Deploying the content created by a Drupal recipe is out-of-scope." which conflicts with the project Roadmap.

Related:

• #2248369: [meta] Deploying configuration that depends on content (hah, already listed by @nedjo a year ago! 👍)
• #3377709: BlockManager is too eager in providing fallback to "Broken" block: it obscures genuine problems

It still smells like experimental default content module in core so it's related in its queue #2849128: Add handling of ConfigEvent::IMPORT_MISSING_CONTENT

Primary blocker is found and fixed #3414993: Add ConfigImporter to \Drupal\Core\Config\Importer\MissingContentEvent