The default content importer should handle Layout Builder section data

As mentioned SectionData has this:

  public function setValue($value, $notify = TRUE) {
    if ($value && !$value instanceof Section) {
      throw new \InvalidArgumentException(sprintf('Value assigned to "%s" is not a valid section', $this->getName()));
    }
    parent::setValue($value, $notify);
  }

This was added in #2926914-30: Rewrite \Drupal\layout_builder\Section to represent the entire section, not just the block info → with no discussion or review comments so I'm not sure why it was done, but it seems feasible to extend this method to accept an array and call Section::fromArray() if necessary.

To me that is preferable to adding a special case for a module to core code.

For the record, I like @longwave's approach better, but opening two MRs anyway just in case there was some reason why the type check was added in https://www.drupal.org/comment/12373836 → . In any event, I didn't remove the type check; just allowed it call Section::fromArray() if it's given an array to work with.

OK, I have thought about it a bit and @longwave's way is about 1,000 times better than my proposed approach. Even if this doesn't land in time, and I have to polyfill it, it's a lot easier to override/decorate a typed data plugin that forking the entire default content importer.

phenaproxima → closed merge request !10525

Test written!

Added some comments to the MR.

I hope ✨ Add a Normalizer and Denormalizer to support Layout Builder RTBC is supporting the Recipes default content import.
(Tested with a playground profile. did not work.) The MR works only with a module, not a recipe.
A Normalizer and Denormalizer in Drupal Core are essential for sections and blocks.

This looks great - a simple fix that allows core's default content to import content created by the default content module plus the layout builder patch from ✨ Add a Normalizer and Denormalizer to support Layout Builder RTBC

@tim.plunkett wants to have a look at this before we merge it.

I agree with @longwavein #2, this would have been a lot more helpful if #2926914-30: Rewrite \Drupal\layout_builder\Section to represent the entire section, not just the block info → had explained how I ended up with this. I definitely recall wrestling with TypedData and the inherent magic-ness of setValue(), and I think I was just trying to save my sanity by having it blow up if something else was passed in.

The change here is sound, and the tests look good.

Committed and pushed a44cf1ef008 to 11.x and 5b1a9182e9f to 11.1.x and 0a5101f68df to 10.5.x and d7f5dbc09cd to 10.4.x. Thanks!

As this unblocks Drupal CMS and after discussion with @longwave agreed to put this in 11.1.x - since it applies also put it in 10.4 and 10.5

This should be in the default content system, not the recipe system.

Hi folks, great work on getting this fixed. I'm using this successfully in my development environments along with the patch in ✨ Add a Normalizer and Denormalizer to support Layout Builder RTBC to propagate layouts.

I've run into an issue that may or not be related. If the original content type for which the layout builder is enabled is imported into a new environment, the layout builder setting is ignored. So I find myself having to manually enable the layout builder across environments. Once I do, then the import process above will work and I can see my custom layouts. Is this a bug perhaps?