🇺🇸United States @thejimbirch

Discussed this aloud and agreed on an approach and testing. I look forward to seeing this progress.

thejimbirch → created an issue.

thejimbirch → created an issue.

Merged

Fixed merge conflict manually, updated some comments.

We still need one patch.

"patches": {
            "drupal/core": {
                "TypeError in CreateForEachBundle when processing config with integer or boolean schema types": "https://git.drupalcode.org/project/drupal/-/merge_requests/13406.patch"
            }
        }

Or via the CLI:

composer config extra.patches."drupal/core"."TypeError in CreateForEachBundle when processing config with integer or boolean schema types" "https://git.drupalcode.org/project/drupal/-/merge_requests/13406.patch"

Since this is a bug in the existing code base, would it be possible to bring this down to 10.x also?

We're needing this in the AI initiative SEO Optimizer recipe → .

Updates links and adds details for contributing.

This looks good to me. Love the example in the comments of the action. Marking RTBC.

Issues all linked.

Validated this works by using it on ✨ SEO Content suggestions Active

Calling all testers! That is beyond my skillset.

I have validated this works in ✨ SEO Content suggestions Active

I have this working for node title, SEO Title, and SEO Description.

Unfortunately, I found a lot of bugs, but fortunately, there are now patches!

"patches": {
            "drupal/ai": {
                "Make setup field widget action config action support bundle wildcards": "https://git.drupalcode.org/project/ai/-/merge_requests/930.patch",
                "AI Automator status field fails on config import": "https://git.drupalcode.org/project/ai/-/merge_requests/932.patch"
            },
            "drupal/core": {
                "TypeError in CreateForEachBundle when processing config with integer or boolean schema types": "https://git.drupalcode.org/project/drupal/-/merge_requests/13406.patch"
            }
        }

MR added.

thejimbirch → created an issue.

I had to reroll the patch to get it to apply. Created a merge request for it, and asked Claude to summarize the changes.

This refactors the config import state tracking to prevent status field modifications during configuration synchronization.

Key Changes:

1. Replaces import toggle function with state checks (lines 41-47, 57-63, 73-79):
- Removes dependency on ai_automators_can_import_toggle() function
- Adds explicit checks for ai_automators.importing state and config.installer syncing status
- Modifies conditions in ai_automators_entity_insert(), ai_automators_entity_update(), and ai_automators_entity_delete() hooks

2. Updates import state management (lines 99-120):
- Renames ai_automators_config_import_steps_alter() hook implementation (previously had incorrect docblock)
- Sets ai_automators.importing state flag to TRUE at import start
- Adds cleanup callback _ai_automators_cleanup_import_state() to batch process
- New cleanup function deletes the import state flag when import completes
Technical Impact:
- Prevents status field modifications when importing config or during config sync operations
- More reliable state management using Drupal's state API instead of toggle function
- Ensures proper cleanup of temporary state after import completes

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

thejimbirch → changed the visibility of the branch hotfix/wip to hidden.

Working on this.

thejimbirch → created an issue.

The AI module has a lot of frameworks that does not actually do anything by themselves, but needs to be setup to work correctly. The AI Automators, AI Search, Field Widgets and AI Agents are all useless without actual setups.

Since AI can solve very specific business cases, its very hard to ship the AI module one-size-fits-all solutions and that's where recipes comes in.

However to be able to utilize recipes correctly we have added some config actions that you can use to setup recipes.

### verifySetupAi
In many cases a recipe doesn't really care if its Gemini or OpenAI behind the scenes, it might just care about what is the capabilities of the model that is setup.

Or we might have 20 recipes that sets up one AI button or AI Agent each and we do not want all of those to be inheriting from a AI Provider setup recipe, when the site might already have a AI provider setup.

This action helps with that - its not actually an action though, its a workaround that check if all the dependencies on the system are met, and if not it will throw an exception so the recipe reverts any changes.

There are 4 things you can verify (and you can mix)

#### provider_is_setup
This takes an array of the providers you want to check for and if they are actually setup and working (API key set, host set etc.).

Example where I want to verify if OpenAI exists and is setup:
```
config:
actions:
ai.settings:
verifySetupAi:
provider_is_setup:
- openai
```

#### operation_type_has_provider
This takes an array of the possible operation types and checks if there exists one provider at least that handles this.

Example where I want to verify if a chat and an image generation model exists:
```
config:
actions:
ai.settings:
verifySetupAi:
operation_type_has_provider:
- chat
- text_to_image
```

#### operation_type_has_default_model
This takes an array of the possible operation types and checks if a default model exists for this.

Example where I want to verify if a chat default model exists:
```
config:
actions:
ai.settings:
verifySetupAi:
operation_type_has_default_model:
- chat
```

#### vdb_provider_is_setup
This does the same as the provider, but checks if a vdb provider is setup.

Example where I want to check if Milvus is setup:
```
config:
actions:
ai.settings:
verifySetupAi:
vdb_provider_is_setup:
- milvus
```

Based on your MR, the Key module does not provide any config actions. The create action comes from core, as does recipe input.

I like the idea of documenting how to add create a key in a recipe, but since the Key module is not creating any actions, this is not the place.

I do have ✨ Add a Recipe Examples section to the docs Active as a placeholder to add a new section to the docs that creates recipe.yml snippets on how to do common tasks. I think your documentation should go there.

Also, for reference, the createIfNotExists config action may be better to use rather than the create action so if the key exists, then the recipe won't fail.

We are moving this part to post-MVP:

Provide a view with all content types and SEO scores similar to the content overview page. Provide a batch operation to analyse multiple pages at once.

Use the custom_field module to add these fields so we can send a single prompt to populate both fields.

We want to use the config actions to validate if the operations we need rather than require Drupal CMS AI recipe.

Moving to needs work.

This could be action-ed.

We are most likely going to be blocked by ✨ Config action to set a third party setting of a display (form or view) component Active

Moving back to Needs work as there is a merge conflict.

This is looking great. I updated the title and a bit of the description.

Moving back to Needs work as there is a merge conflict on the test.

The contrib PWA module is still in beta and only has 2500 installs. I am a fan of the module, but since it was moved to the Drupal CMS issue queue, this issue summary would need to be overhauled for inclusion here.

Would there be a possibility of creating a recipe that would install and configure the module to make it easier for folks in contrib? I feel like that would be a good next step.

Tests are failing. Moving back to Needs work.

Can you include a link to the design?

Great work @ajinkya45! +1 for RTBC

@mlncn I maintain documentation at:

https://project.pages.drupalcode.org/distributions_recipes/recipe_author...

I added an issue to make it clearer on where to find recipes.

📌 Document where to find recipes Active

@nicxvan The distributions_recipes project was a fork of Drupal core. After we got recipes into core, the issues from that project were moved to core. There are a bunch that will need to be re-recreated against core if they are to move forward.

thejimbirch → created an issue.

The Default Content API was added to core as part of the recipes initiative, so that was our priority.

I see no reason that it cannot be extended to import content from modules also as the contrib default_content module does.

In Drupal 11.3, we now have a content exporter!

`content:export` command added to help with recipe development
https://www.drupal.org/node/3533854 →

Thanks to all who helped move this along.

Adding an non-working issue in the contrib module for reference.

Moving the default content system.

With the default_content contrib module, we could export the following types.

node
taxonomy_term
file
media
menu_link_content
block_content
shortcut

I believe all except for file could have a bundle type and would be beneficial for recipe creators.

Back to needs work for additional test coverage requested.

thejimbirch → created an issue.

I can't reproduce this and no one else has reported anything similar.

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

Thanks for the contribution!

All of @larowlan's feedback from yesterday was addressed. Moving back to RTBC for another review.

thejimbirch → created an issue.

That is a valid concern, but one that every project on Drupal.org has to endure. I am looking for a more site builder/marketer friendly way of communicating the functionality of the recipes, and linking to a text file, while it would technically help, it does seem developer-y.

If you wanted to automate the process, would we want to make another script that parses each recipe for name, description, modules, etc and saves that to a README file in each recipe. Then that can be used in the project page desc.

All threads resolved, nits picked, and rebased. Moving back to RTBC.

thejimbirch → created an issue.

Project created at https://www.drupal.org/project/ai_recipe_image_alt_text →

thejimbirch → created an issue.

Work will happen in https://www.drupal.org/project/ai_recipe_seo_optimizer →

Currently blocked by: ✨ Config action to set a third party setting of a display (form or view) component Active

A lot of the recipes folks are looking to build out for DrupalCon Vienna could use this so it would be great if it could be backported to 11.2 also.

What if a site template wants to include an admin theme, or multiple themes (domain access, multisite, etc)?

I'm not sure the development workflow would be fairly easy. Now I have to have a place to work on the theme, and then zip it up, or create a deployment mechanism to do package things up instead of a normal git composer workflow.

Adding ✨ Add a theme configurator so recipes can generate themes Active as related. There is an idea there for recipes, but no work yet.

I feel like this is a must have for CMS, but also recipes in general. Drupal core has Starterkit themes → .

We can generate a clone of an existing theme using a Drupal core script:

php core/scripts/drupal generate-theme my_new_theme

I assume that would could run that from the custom module and it would be done.

But would there be a way that this could be done from within the recipe? It can't be in config actions which my mind immediately went to, because it's not really config relates except for setting the theme as the default.

How else could we do this?

Added this as proposed to the Recipes initiative docs

thejimbirch → created an issue.

I am going to pitch this as a stand-alone AI initiative recipe. Will follow-up here when I do that.

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

Blocked by 📌 Update AI recipe to 1.2 Active

thejimbirch → created an issue.

Ready for testing

thejimbirch → created an issue.

Lets require the Drupal CMS AI recipe to get started. This will allow users to get set up quickly, in a known way, and skip it if it is already set up.

valthebald → credited thejimbirch → .

Adding ✨ Recipes have no way to tell if they're set up for success Active as related and a possible different approach.

Adding #3463641: Create a way for recipes to check their preconditions → as related and possibly not needed.

From @bircher in Slack.

I think they are not duplicates.. or at least the comments mean that they could go in different directions and we could have both.

A) A way to say "sorry this recipe can not be applied, abort"
B) A way to say "this recipe is happy, consider it applied and continue"

A is useful when you want to prevent a recipe messing things up, or you don't have a recipe to depend upon that would set things up for the recipe in question to "just work"

B is useful for recipes that are used as a dependency of others.

But that said maybe we can close the second one because we try to make the config actions more lenient and so there is not that much of a need? although we probably then also could debate whether we need a conditionalConfigUpdate in addition to simpleConfigUpdate because the later will override any customisation a site builder may have added.

thejimbirch → created an issue.

thejimbirch → created an issue.