Provide a Config Action to add/edit a component in a layout

Thought that this could fit in SectionListTrait, but timplunkett pointed out that this would only make sense in config based section lists, so will be its own trait.

Great step forward @penyaskito. Really looking forward to have this in core!

Tried to test it locally to integrate it with navigation module with no luck. Probably I missed one or more steps.

Steps I followed:

• Clone the branch
• Add use ConfigSectionListTrait; to NavigationSectionListStorage
• Implement uuidGenerator() method
• Clear cache at least once
• Execute ddev . php core/scripts/drupal recipe modules/my_recipe
• Get the error: The "addComponent" plugin does not exist. Valid plugin IDs for Drupal\Core\Config\Action\ConfigActionManager are: ....

Create a recipe.yml like this:

name: Navigation Test Recipe
type: Examples
description: 'Adds a block to navigation.'
install:
  - navigation
config:
  actions:
    navigation.block_layout:
      addComponent:
        section: 0
        position: 1
        value:
          uuid: 30000000-0000-1000-a000-000000000000
          id: 'navigation_menu:content'
          label: Content From Recipe
          label_display: 1
          provider: navigation
          region:
            content: 'content'
          default_region: content
          level: 1
          depth: 2

Could you please indicate the steps I missed?

Thank you!

Apparently I was wrong and looking at \Drupal\Core\Config\Action\Plugin\ConfigAction\Deriver\EntityMethodDeriver::getDerivativeDefinitions, ActionMethods are only valid for ConfigEntityTypeInterface implementations, so Navigation will need to declare its own ConfigAction plugin.

So this will only be useful as is for LayoutBuilderEntityViewDisplay in core, and of course contrib.

MR is ready for review. We might want more test coverage for the weight recalculation, but I'd prefer to get feedback on the direction.
I'm not sure how are we testing config actions. Ideally we would have test recipes instead of just testing the method.

We might want to implement this in LayoutBuilderEntityViewDisplay, but not sure if part of the same MR.

Drupal CMS is going to need this, tagging accordingly.

Kicking back for addressing my remaining feedback. :) But I think this is a great start on a helpful action, and I'd really like to see it in core.

Didn't remove the changed I had before yet.

This means that setSection needs to change its visibility from protected to public in SectionListTrait.

Not sure if I implemented the deriver right, but this worked for me with a slightly different version of the previous recipe:

config:
  actions:
    dashboard.dashboard.test:
      addComponent:
        section: 0
        position: 4
        component:
          uuid: 01929a0b-056f-72c1-b390-c9bdc3f6fd5e
          id: dashboard_text_block
          label: 'My new dashboard with weight from a plugin'
          label_display: 'visible'
          provider: 'dashboard'
          region:
            layout_twocol_section: 'second'
          default_region: content
          context_mapping: { }
          text:
            value: '<p>My new dashboard with weight from plugin</p>'
            format: 'basic_html'

This needs better test coverage.

We only cover adding new components. I'd expect we want a separate action for adding multiple components, and a separate one of editing existing components, as @phenaproxima said it would be better to have them separated.
Not sure if we should cover these here or in follow-ups.

The MR only seems to add the "add layout component" action, so I think its far that it only has tests for that. @phenaproxima indicated that these improvements to the tests would be good, that still looks like needs work:

• We need to be sure the region stuff works as expected, including when the default region is used, or the region can't be resolved.
• We need to be sure the position stuff is figured out correctly, every way it could be passed in.
• We need to be sure that the additonal key is preserved if passed.
• The test...isn't using config actions. That obviates the entire point of this MR. We need to test that we can accomplish the addition of the component using config actions. (We don't need to use a recipe, but we probably need ConfigActionManager::applyAction(...).

Reached out to phpstan folks. Learned that 🐛 Add missing @return types for StringTranslationTrait::formatPlural() and ::getNumberOfPlurals() Active is in the way, until that lands, the phpstan baseline needs updating in the MR.

Discussed with @penyaskito and we agreed that this is nice to have, and would accelerate Drupal CMS's dashboard work track, but is not a stable blocker.

Tagging as a target so it's on the radar somewhere, it's intended to be used for nice-to-haves.

Added moar test coverage as requested.

The only remaining comments are about reusing the existing array, but don't think creating a new one and copying every key value (as we don't know the specific block schema) would make it more clear.

The added test coverage looks good IMHO. This part needs a change record I think?

diff --git a/core/modules/layout_builder/src/SectionListTrait.php b/core/modules/layout_builder/src/SectionListTrait.php
index 7a049dec6c40cabdf30343afedd0477d81e4786d..b55fe12ca5432871741e3b26e116d8634cd11148 100644
--- a/core/modules/layout_builder/src/SectionListTrait.php
+++ b/core/modules/layout_builder/src/SectionListTrait.php
@@ -54,7 +54,7 @@ public function getSection($delta) {
    *
    * @return $this
    */
-  protected function setSection($delta, Section $section) {
+  public function setSection($delta, Section $section) {
     $sections = $this->getSections();
     $sections[$delta] = $section;
     $this->setSections($sections);

Is it possible for 2 change records? We have been adding them for new and altered config actions. Something like:

Recipes can now add a component in a Layout Builder layout using the addComponent config action

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.

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

This should be ready, we still need the change record for making public setSections.