🇺🇸United States @thejimbirch

There have been more changes since my lasy post that need to be documented.

Updated the change record to add that you can’t change those two keys.

Thanks @sonfd!

Back to RTBC

Recipes added an "Extra" section in core. https://www.drupal.org/node/3504056 →

The idea is that modules, like Project Browser could consume information from recipes like display a message, or redirect to a page.

I don't know if any additional work has been done on Project browser yet, but this was added specifically for this use case.

Thank you all for your contributions!

@kattia's first commit on Drupal.org

I added link to Recipe Presentations and added a link to Martin's user profile.

Thanks so much for the contribution, and great to see you!

Thanks so much for your contribution!

volkswagenchick → credited thejimbirch → .

Back to RTBC

Looks great, but needs a merge request.

thejimbirch → changed the visibility of the branch 3505369-document-the-new to hidden.

Needs a Merge request and should be added to the table of contents also.

Moving to Drupal core, and postponing on the Drupal Marketplace work.

Moving to Drupal core. Merge request will need to be moved also.

Moving to Drupal core.

Moving to Drupal core.

Moving to Drupal core into the Recipes system component.

thejimbirch → created an issue.

Change record added.

That would be a great place to start, but I hope we can review all the issues.

thejimbirch → created an issue.

The documentation page linked above can be edited by anyone with a Drupal.org profile. Once you've added a recipe, or many recipes, post a comment here so we can give issue credit.

Hmmm, not working and I don't know why. Need to pause on this for now.

Looks good. Marking as RTBC. Will add a change record.

Discussed at DrupalCon to use the name setEntityProperties and use the simpleConfigUpdate style. set and setMultiple will remain, but the new action will be able to handle all the syntax.

config:
  action:
    node.type.article:
      setEntityProperties:
      # Can work on singular
      foo: bar
      # multiple
      cat: dog
      mouse: bird
      # and nested properties.
      nested.thing: yes

This looks good to me today and all comments resolved. Marking as RTBC.

Thanks for that, brain slip. GitLab.

I have no strong opinions either way, as both recipes are always applied, but revisions on content types is only one use. Another is in the config sync screen.

Closing this as Won't do.

But please share your recipe when you create it.

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Since we have revisions for content types turned on, IMHO, we should have the diff module to compare revisions.

Assigning to Pam for approval.

Moving back to Needs work as the PHP tests are failing.

thejimbirch → created an issue.

I ran into the same issue, with images vanishing when I dragged them to a new position in the editor.

We weren't using linked images, but I had the same experience.

Unchecking "Force pasting as plain text" just fixed it for me.

Screenshot added to change record.

Change record added.

Change record added.

Added a screenshot and published the change record.

Change record updated and published.

Change record updated and published.

Updating page status.

One thing keep in mind is that set() does not offer the same functionality, specifically it can only replace a whole top-level property, while SimpleConfigUpdate supports the usual dot based syntax to set child keys directly. Maybe set() should be expanded to have similar capabilities.

As simpleConfigUpdate is in use by most recipe authors on config entities, I feel like we need a suitable replacement that as @berdir points out in comment #16

Updating the title of this issue with the current direction.

Changes looks good. Marking as RTBC assuming the tests pass.

Postponing based on comment in #10

All images were changed to webp except for:

/recipes/drupal_cms_case_study/content/file/drupal-cms-logo.png
/recipes/drupal_cms_project/content/file/drupal-cms-logo.png

The test failure was unrelated, all green now. Moving to RTBC, thanks for your contribution!

When a recipe installs a module, the simple config from that module is imported. So you can't import your own version of that config because it will already exist. Failures abound, config explosions everywhere!%&#@^&$^&!

Instead, in each of the recipe's config actions section, use the simpleConfigUpdate action to rewrite them.

config:
  actions:
    tagify.settings:
      simpleconfigUpdate:
        set_default_widget: true

The Starter Templates idea:
Driesnote: Portland DrupalCon 2022
Dries Buytaert
https://youtu.be/Ig676RzJbLo?t=3180

The first recipes presentation
MAKERS & BUILDERS - Drupal Recipes: From #Driesnote to Initiative
Alex Pott
https://www.youtube.com/watch?v=uNBRLS5zTa8

Drupal Distributions and Recipes Initiative Update
ltrainjohnson, robert-arias
DrupalCon Portland 2024
https://www.youtube.com/watch?v=320Nffq4f44

thejimbirch → created an issue.

As the maintainer of the User Guide I can say that it's a bit of a one off approach, and I'm not sure we should replicate it again.

Thanks for the input. We are going to shift to the mkdocs and use Gitlab pages for publishing.

The https://www.drupal.org/project/ai → has done this, so we can use their code as a guide.

thejimbirch → changed the visibility of the branch 3409318-update-recipes-documentation to hidden.

thejimbirch → changed the visibility of the branch 11.x to hidden.

thejimbirch → created an issue.

Fixed converts to closed fixed after a two week period automatically. Just FYI

The images need to have their original file name remain the same as they are referenced from default content config entities. If the images file names (and/or extensions) are renamed, then the content entity that references them needs to be updated also.

This MR also has only one image updated. The issue summary mentions "images", but did not provide detail. Running the following command in the recipes folder reveals the following images:

find "$PWD" -type f | grep -Ei '\.(jpg|jpeg|png|gif|bmp|tiff)$'

/recipes/drupal_cms_events/content/file/DrupalCon-Atlanta.png
/recipes/drupal_cms_news/content/file/unsplash_John_Schnobrich.png
/recipes/drupal_cms_case_study/content/file/Government-building-EU-flag-credit-pexels-gintare-kairaityte-11923111-17178100.jpg
/recipes/drupal_cms_case_study/content/file/drupal-cms-logo.png
/recipes/drupal_cms_person/content/file/unsplash_Leilani_Angel.png
/recipes/drupal_cms_blog/content/file/DrupalCon-Barcelona-2024 - credit-Bram-Driesen.jpg
/recipes/drupal_cms_project/content/file/pexels-israel-franca-1108173-2101030.jpg
/recipes/drupal_cms_project/content/file/drupal-cms-logo.png
/recipes/drupal_cms_starter/content/file/drupal-cms-hero.png

Moving to Needs work.

This is a duplicate of 🐛 Trash link is a 404 on install because no entity types are enabled Active and is fixed in the next release.

It would be great if, once installed, entity reference fields used the Tagify widget by default instead of the standard autocomplete.

In ✨ SEO Tools recipe should automatically reapply itself every time a content type is created Active we are talking about a recipe that leaves behind an ECA that can applies config actions. So instead of having to re-apply a recipe, to go the SEO fields on new content types in that example, on new content type creation, the ECA applies config actions LIKE a recipe would. If this proves to be possible, I assume it could be used any time a reference field was created.

I'm not sure I agree that altering the source image should be the path here. Shouldn't the image tools creative derivative images create the most optimized images? I haven't had a Photoshop license since Photoshop 3. I also encourage our clients to upload large source image to future proof their content.

thejimbirch → created an issue.

Thank you!

We could surely adjust it so that we don't expose the checkbox -- which would have no effect anyway -- but we do keep the disclosure, or some re-worded version of it.

I like this idea. It provides the message and the user can stop the installation if they don't agree. And we don't have to rely on another package or core to make any changes.

The code is available in standard drupal/core however there is a prompt to reject the tracking while Drupal CMS removed the prompt and disclosure.

Could you point out where this prompt is and how Drupal CMS is removing it? That may help with some options to solve this.

Is there a list of attendees to credit?

The launcher was removedand the documentation was updated in ✨ Replace the launcher script with better documentation Active . Closing as duplicate.

Closing for no response and not much information to begin with.

Drupal CMS installs the https://www.drupal.org/project/automatic_updates → which enables core's updates module.

Should this issue be moved there?

Adding Platform.sh Certified developer badge.