🇺🇸United States @mtift

Looks even better in camelCase!

Good call. I added the change record.

Going forward, the process for validating these config actions will need to be sorted out. It's not clear (to me at least) how strict they should be, or if a recipe should be applied when the config action refers to things that don't (yet?) exist. But this issue is probably not the place to have that conversation.

This plugin works to do something like this (with the minimal profile installed):

name: 'Place a block'
config:
actions:
block.block.whatever:
place_block:
id: minimal_test
theme: default
region: sidebar_second
weight: -10
plugin: system_powered_by_block
visibility: { }

The tests cover other situations, and the PlaceBlock class does a lot of checking already.

This looks great to me. Nice work, @madclu!

Makes sense to me. In conversations at DrupalCon and the recent Starshot webinars (Zoom) meetings I think pretty much everyone who mentioned this initiative called it "Recipes." I don't hear people saying "Distributions and Recipes" so it make sense for the name to match what people are saying.

I'm pretty sure the intention of the change (with the commit message "Example") was to demonstrate a test failure.

mtift → created an issue.

That was it. Thank you @smustgrave!

FWIW, this looks good to me, too.

@alexpott I don't see any comments. Did you add them on https://git.drupalcode.org/project/drupal/-/merge_requests/7910?

This one makes sense to me. All of the reply & redirect issues have been addressed per https://www.drupal.org/node/3452650 → . The deprecation messages and tests make sense. The feedback has been addressed.

However, I applied the MR on a standard install for 11.x with config inspector and got all green checks, but it shows "1 errors" and I'm not quite sure what that is referring to:

So if "every config entity type MUST allow NULL to be set on any class property corresponding to a top-level config entity property" would the implication be that:

  protected array $settings = [];

Gets interpreted as:

  protected array|null $settings = [];

That seems confusing to me.

Removing the reference to book module

Yes, yes, yes! I fully support this proposal. +1

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

mtift → created an issue.

penyaskito → credited mtift → .

minneapolisdan → credited mtift → .

volkswagenchick → credited mtift → .

I think I got them all

Since I'm doing issue queue maintenance, it was suggested that I mark a credit for myself. So I'll do that here.

volkswagenchick → credited mtift → .

volkswagenchick → credited mtift → .

I don't see any code changes here

volkswagenchick → credited mtift → .

Committed to 8.x-1.x

Code looks good, and I can confirm that the patch works. With Upgrade Status enabled and the patch applied, I see this:

minneapolisdan → credited mtift → .

Thanks, all. Committed to 8.x-3.x.

@geekygnr I don't understand why you moved development to GitHub. What does that have to do with "time constraints"?

Whoops, let's try that again

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

I'm not sure why it's anonymous, but your patch fixes the problem and the code makes sense to me. Thanks, @webflo!