Add a Normalizer and Denormalizer to support Layout Builder

@SocialNicheGuru in reply to #57 I tested this and no I don't think it fixes Layout Paragraphs Support

+1 for the RTBC.

Can we get a basic test for that?

Hi,

For information: ✨ Update inline block usage on import RTBC

Current approach just avoids exception & skips "block serialized" approach, which is the default one; @see "\Drupal\layout_builder\Plugin\Block\InlineBlock::getEntity()":

...
if (!empty($this->configuration['block_serialized'])) {
  $this->blockContent = unserialize($this->configuration['block_serialized']);
}
elseif (!empty($this->configuration['block_revision_id'])) {
  $entity = $this->entityTypeManager->getStorage('block_content')->loadRevision($this->configuration['block_revision_id']);
  $this->blockContent = $entity;
}
....

So any serialized block dependencies are ignored, and is the first option when new non existing content block is used in layout builder, besides that approach just works with "inline_block" plugin variants & "InlineBlock instance" can be used instead in order to get it working per base class.

Other case where that should be managed as in layout builder you can mix entity field blocks and content blocks (content) into any display of exported content or its dependencies.

Also some entities like section library template may use same field type to store sections but in different field name, not "layout_builder__layout" but "layout_section", to manage that again "instance of SectionData" can be used instead to detect it.

So taking all use cases would be something like:

1. Content blocks serialized & dependent entities (media or other)
2. Content blocks direct usage & dependent entities (not serialized)
3. Content blocks usage inside any display of exported entity or its dependent entities. Maybe this one is the hardest to manage

Besides changes going in this direction should be compatible with sites without layout_builder module enabled? Maybe all should be managed into import/export subscribers.

Working into patch/mr to manage at least first & second use cases.

To clarify main point, is not just about normalize / denormalize field but also include dependencies (exportContentWithReferences).

Added changes to MR;

1. Avoid layout_builder classes direct use to not force module dependency by missing classes on sites without layout builder enabled
2. Manage serialized block content
3. Use base classes to evaluate instances to avoid strict unique core lb support

Maybe "Drupal\block_content\Plugin\Block\Drupal\block_content\Plugin\Block" should be also supported (direct block content usage from core content block library). Also other possible use cases like commented into #63 -> 3.

Thanks for patch #53, we have tested it in drupal 9.5. And it works correctly.

Would 📌 drush command default-content-export-module-with-references RTBC help too?

The content looks like it exports correctly but then I get this error on import:

In SectionData.php line 35:

  [InvalidArgumentException]
  Value assigned to "section" is not a valid section

I think the function is here in core/modules/layout_builder/src/Plugin/DataType/SectionData.php:

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);
  }

$value is coming in as an array not instanceof Section.

Added test for new normalizer, let me know if I can help more, thanks

Latest patch is working nicely on Drupal 10.3.6.. Both import and export of a Layout Builder page work as expected.

Facing the same issue as in #68, thanks, Jay, for reporting.

Attached a static default_content--2024-11-13--3160146--mr-15.patch static file for MR15
to be used with Composer Patches

The patch in #53 is working
Latest changes over MR5 copied as a static file in #73 misses the order of first block.
and all other blocks in the same Layout Builder get to be positioned in the wrong section or column

Attached a static default_content--2024-12-02--3160146--mr-15.patch file for MR15 from last changes to this point.
to be used with Composer Patches

Not sure if this is the correct place to report this. I'm also getting the Object support when dumping a YAML file has been disabled. error. I saw that another post was closed that reported this error as being a duplicate. We're using layout-paragraphs (gasp) but that hasn't been the issue as we have been successful in the past in exporting and importing this data. We are actually still using the import functionality from our last export nearly a year or two ago but need to update our default content.

I installed the most recent patch and the error occurs at the $return = Yaml::encode($normalized) in the Exporter.php class. Since we have a lot of stuff being exported out I added the following to help me identify the issue

    function find_objects($array, $path = '') {
      foreach ($array as $key => $value) {
        $new_path = $path ? $path . '.' . $key : $key;
        if (is_object($value)) {
          echo "Found object at $new_path\n";
        } elseif (is_array($value)) {
          find_objects($value, $new_path);
        }
      }
    }

    find_objects($normalized);

And it looks like this is erroring out for us on a meta tag breadcrumb item we have on our page. I've included a screenshot from the xdebug if this might be helpful.

Any recommendations?

Paul, it seems like you’re using a custom entity type, possibly a newly custom-coded one, but it doesn’t have Normalizer or Denormalizer support built in.

I realized this after Sascha's comment in #10

phenaproxima → changed the visibility of the branch 3160146-add-a-normalizer to hidden.

phenaproxima → changed the visibility of the branch 3160146-add-a-normalizer to active.

This is going to be important for some recipes in Drupal CMS and was referenced in ✨ The default content importer should handle Layout Builder section data Active

Thanks for the reference. I would expect that this simplifies this issue a lot then, might be enough to normalize/export the structure into the correct format, without special import handling.