Extend recipe runner to create content provided in the recipe's /content folder

This blocks #3418706: [PP-1] Populate the default shortcut set → , which is technically necessary for finishing the Recipe-ification of the Standard install profile in [#3417835.

Is there really nothing we can do here until ✨ Support default content entities Active lands? 🤔

Also, this is at least if not ?

I gave the default_content module a cursory look today and I'm wondering...what if we just, like, added the important parts of it to the recipe system directly?

There are a number of things we don't strictly need from default_content, in order to make recipes import content. For example, the Drush commands are not necessary; neither is the ability to export content. The module also supplies an event-based API, which we could ditch for now. We could also rip out some deprecated material (like support for HAL+JSON-encoded content).

Beyond that, it's really not that complicated of a module.

I think it is an acceptable stepping stone - I think a default content solution belongs in core. That can export and do the other things the module does. But I agree that this feels like a way we can go forward for now.

+1!

So I think that means … this? 😄

Strategically speaking, I might add that getting this done will supercharge #3365143: [PP-1] Model core's Umami install profile as recipes → . Umami has shipped content from day one, and being able to bundle all that as a nice recipe (or set of recipes), instead of having to awkwardly install demo content via an otherwise superfluous module, is going to make recipes an even more attractive solution to automating site building tasks and creating great starting points.

So...full steam ahead!

"supercharge" — I like the sound of that! Full steam ahead indeed! 🚂

omkar.podey → made their first commit to this issue’s fork.

Even if we strip off all the normalise stuff we still need the denormalise for yaml content files right ?, this means a new class for denormalise as it's a lot of code .

#14: Correct, there's no way around that.

Can we make this MR against 11.x recipes - it'll need to land their first.

#14: IMHO we do not need the denormalization as a separate class. I know it's a lot of code, but in the interest of compactness and keeping API surface minimal, I think it's okay for the ContentImporter to be a single class that handles the denormalization as well.

That said, if you really feel it would benefit from being more than one class, I don't feel super strongly.

Right now in the 11.x branch following the default_content module's convention which is to place the .yml file in the entity_type folder under the recipes folder works. You can try that by running php core/scripts/drupal recipe core/tests/fixtures/recipes/only_content.

1. Needs cleaning next as multiple classes are added which could be combined.
2. Needs implementation for handling media files.

Managed to get this sorted out (no pun intended - had to work with the Graph component to make it work), and the test coverage proves that multiple entities of different types are imported in dependency order when applying a recipe that ships content.

I think this is ready for an initial review.

This blocks #3365143: [PP-2] Model core's Umami install profile as recipes → .

A follow-up documentation issue might be required to help understand how content can be created/imported using recipe system.

Filed #3436263: Document how to ship content with your recipes → to document this.

Thanks for the follow-up. One test scenario which is missing here is "Imported node with owned by user that does not exist".
Rest LGTM.

Good call on that test coverage; it found a bug!

I think everything is fixed now.

Looks good to me, moving to RTBC.

alexpott → closed merge request !92

Posted some comments on the MR. This is looking really nice. Just need to sort out the namespace. I suggest Drupal/Core/DefaultContent

When you move it don't forget to update .recipes.gitlab-ci.yml with the new test and code locations.

I think I've addressed all feedback here, except for creating the follow-up.

Added a follow-up and linked it in the code.

I just realized there's a huge blind spot in this MR: we're not testing importing translations!

Definitely need to test that.

Okay, we're now testing translations. That said, there's still a bug here that I need to fix, then split off into its own blocking issue.

First round of review, but this is looking quite good already! 😄

Some requests for test coverage (on top of the ones that @alexpott also asked for and are not yet added), some things that aren't clear, a bunch of nits.

Looking forward to this one landing … but simultaneously somewhat worried that we're importing the same flaws/limitation as the Default Content module has. I have no real-world experience with it though, so I wholly defer to @alexpott making that judgment call. Because unless I'm mistaken, Alex does have quite a lot of experience with it?

I think this change is a great step into moving default content into core and providing recipes with the required functionality.

Committed and pushed b2dbc8f9a44 to 11.x and 838e7391d84 to 10.3.x. Thanks!

I think we should open a follow-up to add documentation. Especially around the expected flow of using the default_content module to create the content.

Already exists: #3436263: [PP-1] Document how to ship content with your recipes →

Automatically closed - issue fixed for 2 weeks with no activity.