Problem/Motivation

Right now, recipes have no way to check ahead of time if they will be able to apply to the current site. They just sally forth and potentially hit a scary exception, which may or may not be helpful.

Proposed resolution

Drupal already has a mechanism for checking preconditions: condition plugins!

Recipes should leverage these by letting them be configured declaratively in recipe.yml. For example:

preconditions:
  configValueIs:
    - 'system.theme:default': olivero
       summary: 'The front-end theme must be Olivero.'
    - 'system.site:mail': 'dukat@terok.nor'
       negate: true
       summary: 'Emails from Drupal cannot be coming from Gul Dukat.'

Each set of conditions is handled by a particular plugin (configValueIs, in this case). Each plugin can accept multiple conditions, and each of those conditions may or may not be negated. Each may also be summarized in a human-friendly way so that the recipe can provide useful feedback if the condition doesn't check out.

The one rule is that all defined conditions must pass, or the recipe will refuse to apply. To use the technical jargon, all conditions are always logically ANDed together. There is no logical OR. If you want to do fancy-pants logic, you need a custom condition plugin.

This also opens the door to adding a --check (or similar) option to the recipe console command, so you can know if a recipe is compatible with your site. Project Browser could also benefit from this.

Remaining tasks

Make it so with tests.

API changes

Recipes will gain new declarative functionality, but condition plugins are a long-standing part of core so this is not going to introduce any API changes or additions.

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue summary: View changes
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue summary: View changes
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue summary: View changes
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue summary: View changes
thejimbirch’s picture

thejimbirch commented

Each may also be summarized in a human-friendly way so that the recipe can provide useful feedback if the condition doesn't check out.

Love this!

b_sharpe’s picture

b_sharpe commented
Status: Active » Needs work

In speaking with @phenaproxima it was determined this might not be entirely the correct approach here and likely needs further discussion before proceeding, marking NW to prevent someone spending time on possibly incorrect implementation.

mohit_aghera’s picture

mohit_aghera commented
Issue tags: +Barcelona2024

Me and @alexpott had a chat during the DrupalCon Barcelona code sprint.
This issue needs issue summary update.

Primarily we are looking for some system that provides the conform for the recipe.
Intention is to validate that the site already has existing features that the recipe is already providing.

This system should be able to validate that current system state has all the necessary configurations applied.

bsnodgrass’s picture

bsnodgrass commented
Project: Recipes Initiative » Drupal core
Component: Code » recipe system

moved to Drupal Core, per https://www.drupal.org/project/distributions_recipes/issues/3513044

sonfd’s picture

sonfd
he/they
Location Portland, ME
commented
Issue tags: +Needs issue summary update
breidert’s picture

breidert commented

We need something like this for Drupal AI as well.

thejimbirch’s picture

thejimbirch commented
Related issues: +#3525303: Create Plugin Action for Recipes to check for installed default provider

Marcus created #3525303: Create Plugin Action for Recipes to check for installed default provider as an idea for this. It won't solve core's issue, but wanted to add it here so folks are aware/

marcus_johansson’s picture

marcus_johansson commented

I can add some perspective on what the AI module needs, since its probably a little bit different to most other use cases.

The AI module has at its core a normalization/abstraction layer of AI Providers like OpenAI or Anthropis. This is based on abstracted so called operation types with capabilities. These are usually built on input, output and similarity of feature set.

The most normal operation type is the Chat operation type where a model like gpt-4.1 or claude-3.7 from different providers works. Another could be text-to-image where Stable Diffusion or Dall-E exists.

On top of that we have capabilities, so for instance for an agentic system its vital that the Chat system handles so called tool calling.

To make sure that everyone that creates third party modules that interacts with the abstraction layer, we have made sure that when you install and setup a new provider, it can say that its the default provider/model for any combination of these operation types and capabilities. You also have a settings form where you can set or change this yourself.

At time of writing we have 20+ providers, where almost all of them has a unique use case for the right customer/consumer.

But for the third party app, it doesn't matter which provider is running in the background, it sends input and receives output in a normalized way.

This means two things for recipes where the AI module probably differs:

  • When setting up a provider, we only want one recipe per provider, since we can't have 20 composer dependencies and up to 30 prompts asking for different api keys/setup instructions in bash. These recipes can be good for internal usage, where you want to setup the same thing over and over, but generally are not that helpful if you just use them once, since setting up in the GUI is usually easy.
  • To not create a lot of boilerplate config, the recipes that actually provides advanced setup of AI functionality, should not have to concern themselves with setting up the AI provider, this should have been done already. They should also not need to depend on a specific provider recipe, since that defeats the purpose of normalization.

So we need a way to determine if an operation type/capability is set and the recipes should just have to verify this part and nothing else. That would be the most optimal way of working for us.

marcus_johansson’s picture

marcus_johansson commented

I can note that #3525303: Create Plugin Action for Recipes to check for installed default provider is a workaround for this, but the config action plugin system is obviously not where this logic belongs.

thejimbirch’s picture

thejimbirch commented
Related issues: +#3461946: Recipes have no way to tell if they're set up for success

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

fago’s picture

fago
Primary language German
Location Vienna
commented
Priority: Normal » Major

Currently missing this feature as well. It seems like this has been a frequent request / missing part, so I'd say this is major for recipes.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.