🇺🇸United States @thejimbirch

Nice catch, thanks! Updated it.

The Config Actions API was added to Drupal core in 10.3. Closing this as outdated.

Yes! Thanks so much for all your hard work @mandclu, and @mtift for reviewing!

@mandclu. For a better developer experience, we've decided to unify the config actions to use camelCase. Could you update this action to placeBlock?

For reference, see:
https://www.drupal.org/project/drupal/issues/3455113 ✨ Rename ensure_exists to createIfNotExists, and camel-case simpleConfigUpdate for consistency RTBC

Since this is also a single issue, I think this should go against core. I am going to update this issue, but can you update the MR to be against core?

The patch is not currently needed as the recipes functionality is in core. All the functionality you need is available without the patch.

We have not made additional changes, so the patch is empty. The initiative may continue to commit larger efforts to this project where the patch will be helpful. There are just no changes at this time.

Closing this issue as works as designed.

To test the functionality you could use the Drupal PHP script to install Drupal without the need for an install profile.

From the Drupal root run:

php core/scripts/drupal install core/recipes/minimal

Hi Prashant Chauhan,

Please remove those additional files you added. They are not needed. We don't need to copy and paste the files as they are in the profile. Our goal is to create the same functionality using the new tools.

The config files in the profile had to replace all of the functionality of the core module. Recipes do not need to recreate the whole thing. We only need to change the bits that need changing. In both files, there is only one small change in each that we can make using config actions in the recipe.yml.

Lets take a look at the differences in user.settings:

Here is how we are applying this single change:

The same applies to the system.theme.global config:

And again, here we are applying this single change in the recipe.yml using config actions:

Thank you so much; this is excellent work. Marking as RTBC.

Regarding the name change. In a recipes leadership call earlier this week, we hashed out what ensure_exists really did, and want we want it used for.

1. ensure_exists currently verifies that the config exists by it's id and nothing else.
2. If the config exists it skips doing anything to the fields and moves on.
3. If the config doesn't exist, it creates the config in Drupal with the values entered.

This is a much more lenient approach to recipe dependencies vs. having config in the /config folder because it simply has to exist and not match exactly.

I don't see how this is metatag module related as you said, it is not meta data related, will not print in the head.

I have however done similar things. A second field field_h1 and a minor if statement in twig templates would do the trick.

I think the challenge would be to have a content admin look to the metatag field in that admin UI for this. I would think this field should be right next to the title/label field.

thejimbirch → created an issue.

Thanks for moving this along @zetagraph and @Gábor Hojtsy!

I posted this in the slack convo as there were some other voices there. Posting her for posterity and to continue the conversation.

Thanks folks for moving this along. I will update the issue also. I don't have any objections to using the initiative logo for the Standard recipe. However, what would a log look like for the Umami and Minimal (if we have one) recipes?

thejimbirch → created an issue.

We create follow-up issues to document changes/additions in the Recipes Initiative project to the 1.0.x branch.

According to the config action documentation, there are two:

simple_config_update
ensure_exists

Ah, @mikelutz is correct. THe MR needs to be against core, not the D&R project.

Thanks for answering my questions! I updated my examples in #26 to use setMultiple.

This is a great step forward for Actions. I am marking as RTBC.

A blog could use the article content type from the Standard recipe. It should use the "BlogPosting" Schema.org vocabulary as specified in:

https://developers.google.com/search/docs/appearance/structured-data/art...

Adding Article structured data to your news, blog, and sports article pages can help Google understand more about the web page and show better title text, images, and date information for the article in search results on Google Search and other properties

Event content type should follow Google specified schemas as defined at:
https://developers.google.com/search/docs/appearance/structured-data/event

The event experience on Google makes it easier for people to discover and attend events through Google Search results and other Google products, like Google Maps.

Hiding MR 138 as 142 is the correct one.

Moving back to Needs Review to please the bots.

thejimbirch → changed the visibility of the branch 3447994-example-recipe-isnt to hidden.

thejimbirch → changed the visibility of the branch 3454444-author-guide to hidden.

thejimbirch → changed the visibility of the branch 3454444-document-the-reason to hidden.

Need to fix coding standards.

Based on discussion with Phenaproxima in https://drupal.slack.com/archives/C2THUBAVA/p1718367577268629

We don't need the standard_roles recipe if we have both of the roles broken out.

We are also going to simplify the need for additional files and use the ensure_exists config action to create the config if it doesn't exist.

Thanks for reporting. Added this issue to the Recipes Phase 2 roadmap under "Improve the recipe application process"

https://www.drupal.org/project/distributions_recipes/issues/3446089#reci... →

Updating title for clarity.

Actually, let's make this even more composable as outlined in the docs. It would be very common for a recipe author to want to install just the Administrator role, and not the Content editor.

thejimbirch → created an issue. See original summary → .

This issue is simple enough. Moving to the core recipe system.

Should be added to:
https://git.drupalcode.org/issue/distributions_recipes-3381259/-/blob/33...

We also decided that we could use NULL to bring in only the module's simple config. That should be tested and documented.

thejimbirch → created an issue.

Its not in our Phase 2 roadmap. Looks like Wim opened it to add [PP-2] to the title, which is Postponed on 2 issues.

But that doesn’t take into account the overrides set in the UI, right?

Thank you!

We need a decision point in ensure_exists, or similar actions that offer different paths.

The decision point is what to do at the point where the recipe runner finds or doesn't find a config while applying an action.

1. ignore/skip: If I find the config, skip this
2. apply/combine: If I find the config, add this
3. replace/force: If I find the config, replace this
4. create: If I don't find the config, do this

config:
actions:
example.machine_name
ensure_exists:
id: machine_name
directive: ignore/skip, apply/combine, replace/force, create

I feel like this would greatly increase the interoperability of recipe application, especially when harnessed with the little used create config action.

The following is a rewrite of core's Remote video media recipe. Instead of having a /config folder where config files live, we are using the create action to have it all in a single recipe file.

name: 'Remote video media'
description: 'Provides a media type for videos hosted on YouTube and Vimeo.'
type: 'Media type'
install:
  - image
  - media
  - media_library
  - path
  - views
config:
  import:
    media_library:
      - core.entity_view_mode.media.media_library
      - core.entity_form_mode.media.media_library
      - image.style.media_library
      - views.view.media_library
    media:
      - core.entity_view_mode.media.full
      - system.action.media_delete_action
      - system.action.media_publish_action
      - system.action.media_save_action
      - system.action.media_unpublish_action
      - views.view.media
    image:
      - image.style.medium
  actions:
    media.type.remote_video:
      create:
        langcode: en
        status: true
        dependencies: {  }
        id: remote_video
        label: 'Remote video'
        description: 'A remotely hosted video from YouTube or Vimeo.'
        source: 'oembed:video'
        queue_thumbnail_downloads: false
        new_revision: true
        source_configuration:
          source_field: field_media_oembed_video
          thumbnails_directory: 'public://oembed_thumbnails/[date:custom:Y-m]'
          providers:
            - YouTube
            - Vimeo
        field_map:
          title: name
    field.storage.media.field_media_oembed_video:
      create:
        langcode: en
        status: true
        dependencies:
          module:
            - media
        id: media.field_media_oembed_video
        field_name: field_media_oembed_video
        entity_type: media
        type: string
        settings:
          max_length: 255
          case_sensitive: false
          is_ascii: false
        module: core
        locked: false
        cardinality: 1
        translatable: true
        indexes: {  }
        persist_with_no_fields: false
        custom_storage: false
    field.field.media.remote_video.field_media_oembed_video:
      create:
        langcode: en
        status: true
        dependencies:
          config:
            - field.storage.media.field_media_oembed_video
            - media.type.remote_video
        id: media.remote_video.field_media_oembed_video
        field_name: field_media_oembed_video
        entity_type: media
        bundle: remote_video
        label: 'Video URL'
        description: ''
        required: true
        translatable: true
        default_value: {  }
        default_value_callback: ''
        settings: {  }
        field_type: string
    core.entity_form_display.media.remote_video.default:
      create:
        langcode: en
        status: true
        dependencies:
          config:
            - field.field.media.remote_video.field_media_oembed_video
            - media.type.remote_video
          module:
            - media
            - path
        id: media.remote_video.default
        targetEntityType: media
        bundle: remote_video
        mode: default
        content:
          created:
            type: datetime_timestamp
            weight: 10
            region: content
            settings: {  }
            third_party_settings: {  }
          field_media_oembed_video:
            type: oembed_textfield
            weight: 0
            region: content
            settings:
              size: 60
              placeholder: ''
            third_party_settings: {  }
          path:
            type: path
            weight: 30
            region: content
            settings: {  }
            third_party_settings: {  }
          status:
            type: boolean_checkbox
            weight: 100
            region: content
            settings:
              display_label: true
            third_party_settings: {  }
          uid:
            type: entity_reference_autocomplete
            weight: 5
            region: content
            settings:
              match_operator: CONTAINS
              match_limit: 10
              size: 60
              placeholder: ''
            third_party_settings: {  }
        hidden:
          name: true
    core.entity_form_display.media.remote_video.media_library:
      create:
        langcode: en
        status: true
        dependencies:
          config:
            - core.entity_form_mode.media.media_library
            - field.field.media.remote_video.field_media_oembed_video
            - media.type.remote_video
        id: media.remote_video.media_library
        targetEntityType: media
        bundle: remote_video
        mode: media_library
        content: {  }
        hidden:
          created: true
          field_media_oembed_video: true
          name: true
          path: true
          status: true
          uid: true
    core.entity_view_display.media.remote_video.default:
      create:
        langcode: en
        status: true
        dependencies:
          config:
            - field.field.media.remote_video.field_media_oembed_video
            - media.type.remote_video
          module:
            - media
        id: media.remote_video.default
        targetEntityType: media
        bundle: remote_video
        mode: default
        content:
          field_media_oembed_video:
            type: oembed
            label: hidden
            settings:
              max_width: 0
              max_height: 0
              loading:
                attribute: lazy
            third_party_settings: {  }
            weight: 0
            region: content
        hidden:
          created: true
          name: true
          thumbnail: true
          uid: true
    core.entity_view_display.media.remote_video.media_library:
      create:
        langcode: en
        status: true
        dependencies:
          config:
            - core.entity_view_mode.media.media_library
            - field.field.media.remote_video.field_media_oembed_video
            - image.style.medium
            - media.type.remote_video
          module:
            - image
        id: media.remote_video.media_library
        targetEntityType: media
        bundle: remote_video
        mode: media_library
        content:
          thumbnail:
            type: image
            label: hidden
            settings:
              image_style: medium
              image_link: ''
              image_loading:
                attribute: lazy
            third_party_settings: {  }
            weight: 0
            region: content
        hidden:
          created: true
          field_media_oembed_video: true
          name: true
          uid: true

Note: you will have to clear the cache after applying this recipe to avoid a WSOD.

With the proposed changes, the action to skip adding the media type if it already exists would be:

  actions:
    media.type.remote_video:
      ensure_exists:
        id: remote_video
        directive: skip
      create:
        langcode: en
        status: true
        dependencies: {  }
        id: remote_video

This would allow the recipe to continue to apply if it encounters it and it is not exactly what is expected. This action could be applied to all of the fields and displays in the recipe allowing for granular decisions if needed by the recipe.

If this proposal is accepted, moving forward, I feel we need to:

1. Extend the ensure_exists action to have the directive option, or add additional actions.
2. Update the core recipes as needed to use the options as needed.
3. Update the documentation around the ensure_exists and create actions.
4. Review the issue queue, especially the Improve the recipe application process → section of the phase 3 roadmap to see which of those issues could be closed if they updated their recipes to this workflow.

That should be a great place to start!

griffynh → credited thejimbirch → .

Created #3452995: [Meta] Support automated tests of recipes → and added it here per @alexpott in #32

thejimbirch → created an issue.

@zetagraph

For your #1) This issue is not about the Starshot recipes. Those recipes will most likely come from contrib and not Drupal core.

The Drupal core recipes can be found here: https://git.drupalcode.org/project/drupal/-/tree/11.x/core/recipes?ref_t...

But see the comments in #6; we haven't yet determined which of those recipes will need/should have images.

#2) At this time, I assume so, but work is ongoing in the Project Browser initiative to add support for recipes.

#3) If there were an issue and need for a "don't have an icon" logo, I believe it would also be in the Project Browser initiative.

Adding #3421666: Decide and update recipe naming and classification standards → as a dependency as the recipe's type, or other classification will most likely need to be used in determining which recipes are available to Project Browser's filters and the installer.

As an ambitions site builder, wouldn't I want the ability to discover everything I can do with Drupal?

I agree that the installer should list only certain recipes to start, and even an initial load of project browser. But I feel like I should be able to filter/expand to see all available options.

These are all of the types from the standard recipes:

Administration
Block type
Comment type
Contact form
Content field
Content type
Maintenance
Media
Media type
Performance
Search
Site
Taxonomy
Text format
Text format editor
Themes
Users
Workflow

Updated.

https://www.drupal.org/about/starshot/initiatives/recipes →

The Recipes code is in Drupal core. You don't need a patch currently. Just use Drupal 11 and the functionality is there.

The patch will be for future work on this initiative.

Phase 1 has been completed and merged into Drupal core. Additional work continues in the initiative space to help move Starshot forward.

Should this be updated to speak of Recipes instead of Install profiles?

Added specifications to the documentation and created a core issue to add logos to core recipes ✨ Recipes in Drupal core should have a logo for findability in Project Browser/Starshot Active .

Since you created this issue, I am going to take your word for it!

Closing as duplicate of [##3446257]

thejimbirch → created an issue.

This is based on the requirements of Project Browser and Gitlab. Ultimately, for now, we need PNGs due to this open GitLab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/13897

The Project Browser Image specs are in this issue: https://www.drupal.org/project/project_browser/issues/3342533 📌 [Meta] Create a logo for a contrib module Active

The postponed discussion about SVGs is here: https://www.drupal.org/project/project_browser/issues/3311380 ✨ Prefer SVG format, but allow PNG for logo? Postponed: needs info

thejimbirch → created an issue.

Moving back to Needs work based on the comment in #21

Perfect, thank you!

Hi,

This issue is in my phase 2 roadmap under the Improve the recipe application process epic. See #3446089: [Meta] Recipes Phase 2 Roadmap → .

I love the idea of your #3, and already have some "snack" sized recipes like a 90 Day Password Policy and YouTube Lite Embed.

We just landed recipes and default content into core a few weeks ago as experimental. Our goal for phase 2 is to iterate and improve, and work to ensure recipes as a foundation can support the Starshot initiative.

Most of the work in this initiative has been done by a very small group. If anyone is interested in helping move this issue forward, we would gladly accept the help.

We have an asynchronous meeting every two weeks.
#3269687: [Meta] Distributions and Recipes Initiative meetings - Next: June 4th, 2024 →

We monitor the #recipes channel of the Drupal slack.

We have a Recipes and Starshot Webinar scheduled → for June 11, 2024 - 15:00 - 16:00 GMT

Prioritized the epics for Starshot.

@vbouchet I haven't used that module in a recipe. But try this:

config:
  actions:
    antibot.settings:
      simple_config_update:
        form_ids: webform_*

thejimbirch → created an issue.

Yes, but that hasn’t come to fruition yet.

Project Browser's guidelines for modules:

https://www.drupal.org/docs/contributed-modules/project-browser/module-m... →

Logo

Design a logo for the module.
Create a logo that is 512x512 square dimension in PNG format without animations. Suggested file size should be 10k or less. (Please note: you should not round the corners in the PNG itself, unless there is some compelling branding reason. We will round corners when displaying in the Project Browser.)
Use a lossy image tool (such as pngquant) to reduce file size while keeping the image quality at around 80%.
Place the logo in the root directory of the Git repository for your project, on the default branch. The logo file should be named logo.png. The logo will be placed on Drupal.org project pages to the left of the project name. For example, Project Browser has a logo.png file. Logos are cached and may take up to an hour to show.
If you previously added a logo as the first image on the Drupal.org project page, please remove it.

thejimbirch → created an issue.

Thanks @Wim Leers. That makes sense.

Also need to document:

set:
setMultiple:
removeComponent:

+1 for RTBC