#Needs change record

Re #5: Yeah, I'm not necessarily saying it's a workflow that anyone would actually use, but I merely raise it because people have all sorts of wonky workflows and this could be a major change to some of them. I guess this is merely a call for strong documentation.

This is probably the riskier proposition, since deployments that depend on doing a composer install at the remote end, then reapplying the recipes, will not work

Trying to think of a use-case for this workflow, but struggling a bit.

I would expect that people would apply the recipes locally, export configuration, and commit the configuration to git, then import it on production (same as config changes without recipes). Or.. if they're building a recipe-based hosted demo or similar that they'd commit the recipes themselves to git. As long as those two work, then breaking a workflow of composer install locally + recipe apply remote without either exporting config or committing to git seems fine.

#2702061-106: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) → and downwards is relevant, but the most likely outcome would be that the number of different elements is reduced, and eventually #theme gets dropped in favour of #type component, but don't really see any reason that this couldn't all be worked on in parallel without explicit dependencies.

joegraduate → changed the visibility of the branch 2672340-remove-user_user_role_insert to hidden.

Any chance of a patch against latest D11 stable release?
I could not get it working based on the MR diff/patch, tried to fix it manually but I was out of my depth there...

Updating version to the version of the commit.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Yes, agree #142 is nicer and it also gels with some thinking I had in this experiment

It also means we might not have to add new classes for everything, we could possibly use the existing render element plugins but instantiate them.

Rebased MR 12000

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

New test passes.

Missed bringing over the Twig function

dcam → changed the visibility of the branch 3174255-docreate-invalid-bundle to hidden.

If this change is made, Attribute support must also be changed.

Works for me

I think that @berdir in #15 is right and we should avoid this, modules installing other modules should let the newly installed module handle updates to itself.

Just following up 1 more if this is still a valid task? If no follow up in 3 months could close out.

All tests green

Rebased

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.