🇺🇸United States @thejimbirch

Can we not actually ship the site template recipes with Drupal CMS, and instead require them on application?

Leaving recipes in the code base of an existing site leads to dependency locking and can block site owners from updating.

We have already seen this on Drupal CMS 1.0, where users will have to update the SEO Tools recipe in order to update the field_group module from v3 to v4. Recipes were designed to be ephemeral and not stick with the site they have been applied to for these dpendency issues.

Now that recipes are unpacked in Drupal CMS 2.0, and project browser can be used to list projects from APIs, we should be able to fulfill the requirement to offer three site templates to Drupal CMS, but not actually "ship" them in the code base.

Thanks for the RTBC @smustgrave. It’d be great to see this backported.

Patch added from the diff of the MR.

Merge request added that makes Equal the default, selected choice and moved Advanced to the end.

This way, a user does not have to make make any changes on the layout screen and the grid will render as expected.

thejimbirch → created an issue.

Added Needs change record tag.

They are downloaded into the vendor folder because the project needs to be set up correctly. Drupal core’s recommended template should be linked as a guide. 
 

if you use drush to apply a recipe, you donated to cd into the web root. Drush always runs there. If you use the Drupal php script, you do need to cd into the web root. 
 

I’m not sure we want to maintain a page here when we already have the project documentation 

Added the link back, and links to the recommended link.

Adding credit for discussions in slack.

Adding Needs change record tag.

thejimbirch → created an issue.

Created a follow up issue in the Recipes component of core.

thejimbirch → created an issue.

In my recipes, I remove the

field_

and replace it with sa_ (for saplings). There is a secret simple config called field_ui.settings where you can change it.

I call it secret because it has no UI, you need to change it in the config and then import it.

This is expected. The event recipe treats the field_date strictly. Meaning if there is a field_date in the system, then it HAS to look exactly the same as it does in the recipe, and if it doesn't, it should fail.

Here is where that is in the recipe.

https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/recipes/drupal_...

Updated issue summary

thejimbirch → created an issue.

system.site is a simple config file, not a config entity. For those you can use the simpleConfigUpdate config action.

name: Test Recipe
description: A recipe to change the site name.
type: Site
  actions:
    system.site:
      simpleConfigUpdate:
        name: "Ipsum Lorem"

The code in this merge request looks fine, but I think the ideal situation would be to also remove the recipes from the code base.

Like project browser can list and install projects from Drupal.org's JSON API, I feel like we should also have a browser that would list the approved Drupal CMS recipes from Drupal.org. When a user chooses to apply a recipe, the recipe is downloaded, applied, unpacked, and removed in one step.

That way, the recipe is truly ephemeral, and the user gets the latest version when they choose to browse and apply.

Great approach. Re-running tests as the failures seem unrelated.

Moving to RTBC assuming the tests pass.

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

Added some MR comments.

thejimbirch → created an issue.

thejimbirch → created an issue.

Adding the correct tag, MidCamp 2025.

Adding the correct tag, MidCamp 2025.

Adding the correct tag, MidCamp 2025.

Nope, you had it right!

Updating the tag to MidCamp 2025 Contrib

Closing. Thanks for the contribution!

Closing, thanks for the contribution!

Thanks for the correction!

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

Updating tag.

Edited for a typo and to make the comments below 80 characters like Drupal likes.

Great job! Moving to RTBC.

paulsheldrake → credited thejimbirch → .

thejimbirch → created an issue.

thejimbirch → created an issue.

Love this idea!

Amber Matz has created amazing documentation for the module at https://new.drupal.org/drupal-cms/promote/using-seo-checklist-in-drupal-cms

We should add the links back to the checklist items and links to the sections of this page.

The configuration 'image.style.ai_image_alt_text' exists already and does not match the recipe's configuration

This error is happening because you already had an image style named ai_image_alt_text, but it was changed and different from the one the module provides.

I reviewed the recipe and the module's config, and they doesn't seem to be any reason to treat the config strict, so I made it lenient.

To validate, apply the recipe, change a setting in the image style, and then re-apply the recipe.

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

Thanks for the work, the explanation and the inline comments. I made one more minor change to fix coding standards and now all the tests are green. Removing Needs tests tag and I will add a change record.

Noting this should also close 🐛 Claro installed by recipes has incorrect block config Active

Removing this issue as a related issue.

Removing duplicate related issue

Adding Needs tests tag back in. I am awful at this. If I attempt again, I will assign it to myself but if anyone want to work on this, I will thank them profusely.

Added tests and got everything to green. I used AI to help me put this together as I am still pretty green to writing tests.

The 3 tests are:

testNoBlocksCreatedDuringConfigSync
Verifies that block_themes_installed() does not create blocks during a config sync.

testBlockHooksModulesInstalledDuringSync
Confirms BlockHooks::modulesInstalled() avoids block creation during config sync.

testBlockHooksModulesInstalledWithoutSync
Ensures BlockHooks::modulesInstalled() does create blocks when not syncing.

Looks like it was removed in this big commit, but I don't see where it was replaced if so.

https://git.drupalcode.org/issue/drupal-3524547/-/commit/48c71f0598fe877...

thejimbirch → created an issue.

Thank you for this. Moving to RTBC.

This looks great. Moving to RTBC. I also added a change record.

thejimbirch → created an issue.

Does it need to be removed from core? A site template late could still require and apply it if the recipe were in core.

hestenet → credited thejimbirch → .

hestenet → credited thejimbirch → .

hestenet → credited thejimbirch → .

hestenet → credited thejimbirch → .

Discussion mentioned in #7

https://drupal.slack.com/archives/C2THUBAVA/p1743738585491189

Did we decide, ultimately, that we were not going to unpack recursively? Or is this a bug?

I believe we decided that recipes would be unpacked recursively. That is the only way we'd ensure the functionality of those recipes can be maintained moving forward.

@kunalgautam

simple_sitemap_engines is a submodule of drupal/simple_sitemap.

This line in the composer.json file should be removed as it is not needed. The submodule gets required when drupal/simple_sitemap is required.

"drupal/simple_sitemap_engines": "^4.2.2",

@gbyte How is the key generated, and how is it saved? I assume we can use config actions in a recipe to save it, but not sure how a recipe could generate the key.

amber himes matz → credited thejimbirch → .

For the .gitignore section, I think we can add something like this:

cd /path/to/repo
find . -name "/recipes*" >> .gitignore

------------

To add a repository, it's

composer config repositories.<name> <type> <url>

Example:

composer config repositories.drupal composer https://packages.drupal.org/8

This will automatically inject into composer.json under repositories like this:

"repositories": {
    "drupal": {
        "type": "composer",
        "url": "https://packages.drupal.org/8"
    }
}

------------

To update the allow-plugins section for the unpack command:

The general syntax is:

composer config allow-plugins.<plugin-name> true

For our specific case:

composer config allow-plugins.ewcomposer/unpack true

thejimbirch → created an issue.

Hi Ressa,

Thanks for the issue. There is already an initiative called Member Platform that you can find at https://www.drupal.org/project/member → .

I am going to move this issue there from the Recipes Initiative project for better visibility and discussion.

SEO dashboard was removed from Drupal CMS. Closing.

My scenario is a higher ed university site that has a main site staff, and 500+ group sites. We would want so media creation for the main site staff, but do not want to share the Ai tokens with all the group sites.