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?