We should add a new section to the docs that creates recipe.yml snippets on how to do common tasks.

* How to add a field to every content type

https://github.com/kanopi/saplings-fields-seo/blob/main/recipe.yml

* Ask for a role's machine name and add permissions to it.

user.role.${role_name}:
  createIfNotExists: ...
  grantPermission: ...
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

thejimbirch created an issue. See original summary.

koppie made their first commit to this issue’s fork.

koppie’s picture

Assigned: Unassigned » koppie
Status: Active » Needs review

Following up on @thejimbirch's comment in https://www.drupal.org/project/distributions_recipes/issues/3549058#comm.... I've opened a new MR that does the following:

  1. Creates a new page for "Common Tasks"
  2. Adds the page to the table of contents
  3. Fixes the numbering in the toc

This is ready for review!

phenaproxima’s picture

Status: Needs review » Needs work

I had to open the MR; pushing a branch doesn't automatically open one. You should still be able to push changes, though.

That said, I reviewed the changes and it doesn't look like this does what is specified in the issue summary here...? I don't know if I'm on board with the phrasing that it creates a config entity "interactively", because that's not really true. It's more like the recipe will create a config entity and certain aspects of it can be specified interactively.

How about we add three examples to this new page:

  1. How to add an existing field to every content type
  2. How to add permissions to a role, whose ID is specified by an input
  3. How to get an API key or other user input and store it in config (a reworking of what you've already done here)

Sound reasonable?

thejimbirch’s picture

Another:

https://drupal.slack.com/archives/C2THUBAVA/p1724874830469789?thread_ts=...

To add and configure new fields in field groups.

Create the field storage configs and put them in the /config folder. These will be idempotent because nothing can ever change on them (I'm pretty sure that is true).
Use addToAllBundles to create the field instances on every type (what would you do if you only wanted it on one or 2 bundle types?)

field.storage.node.field_seo_analysis:
      addToAllBundles:
        label: 'SEO Analysis'
        description: 'Pick the main keyword or phrase this page is about.'

3. Use setThirdPartySettings to create the field_groups

      # Configure field group.
      setThirdPartySettings:
        - module: field_group
          key: group_administration
          value:
            children:
              - group_content
              - group_seo
            label: Administration
            region: content
            parent_name: ''
            weight: 1
            format_type: tabs
            format_settings:
              classes: ''
              show_empty_fields: false
              id: 'group_administration'
              label_as_html: false
              direction: horizontal
              width_breakpoint: 640
        - module: field_group
          key: group_content
          value:
            children:
              - body
              - field_image
              - field_tags
              - field_when
              - field_where
              - field_location_address
              - field_location_telephone
            label: Content
            region: content
            parent_name: group_administration
            weight: 20
            format_type: tab
            format_settings:
              classes: ''
              show_empty_fields: false
              id: 'group_content'
              label_as_html: false
              formatter: open
              description: ''
              required_fields: false

NOTE: Tabs may not be the best thing to do as once you do tabs, all the fields should be in the tabs or it looks funny. But the good news is you can have a bunch of field names in the children section and it doesn't break it if a bundle doesn't have that field.4. Use setComponent(s) to add the fields in the form and display

     setComponents:
        -
          name: field_seo_analysis
          options:
            type: yoast_seo_widget
            weight: 18
            region: content
            settings:
              render_theme: olivero
              render_view_mode: default
              edit_title: 0
              edit_description: 0
            third_party_settings: {  }
        -
          name: field_seo_description
          options:
            type: string_textarea
            weight: 16
            region: content
            settings:
              rows: 5
              placeholder: ''
            third_party_settings: {  }
koppie’s picture

Assigned: koppie » Unassigned

> Sound reasonable?

Sorry @phenaproxima, but no. I'm volunteering my time. My motivation was that I spent hours trying to write a recipe that could take user input and save a value using the Key module. There's still no documentation for that, and I wanted to contribute.

phenaproxima’s picture

Assigned: Unassigned » phenaproxima

Fair enough. I do love the idea of a comprehensive set of examples, but I'm trying to ensure it is clear about what each example does. I'll try retooling the MR to clear up some phrasing, while keeping your example (which I think is a good one!) intact.

phenaproxima’s picture

Assigned: phenaproxima » thejimbirch
Status: Needs work » Needs review

Retooled the phrasing and example slightly, in the hopes of making it a little clearer (I also fixed a bug that will actually totally prevent that recipe from working at all as-written). Assigning to Jim for review.

thejimbirch’s picture

Awesome, merge that MR. Leaving this open to add :

* How to add a field to every content type

We could also expand the Key scenario to use a file that is in private files, which is a common example on Pantheon.

thejimbirch’s picture

Status: Needs review » Needs work
nedjo’s picture

No doubt there's a point to be made that two is kinda few to start with, and fair, but personally I'd lean towards getting this in as is. It's a valuable start in and of itself. That's what our recipe documentation is: a collaborative work in progress. We can pull the remaining ideas from this issue into followups. If anything, getting what's already in this MR into the public-facing docs should get more eyes on this work and up the chances of getting more tips flowing in.

Just my 2c.

thejimbirch changed the visibility of the branch 3526093-add-a-recipe to hidden.

thejimbirch changed the visibility of the branch 3526093-add-a-recipe to active.

thejimbirch changed the visibility of the branch 3526093-add-menu-link to hidden.

thejimbirch’s picture

Status: Needs work » Fixed
Issue tags: +Chicago2026

Merged, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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