[PP-1] Expose Layout Builder data to REST and JSON:API

Great start :)

1. Thanks for having a @DataType-level normalizer! This is in line with #2926507: Discourage @FieldType-level normalizers, encourage @DataType-level normalizers, to strengthen the API-First ecosystem! It also means this will work with JSON API :)

2. +++ b/core/modules/layout_builder/layout_builder.services.yml
   @@ -39,3 +39,11 @@ services:
   +      - { name: normalizer, priority: 1 }
   ...
   +      - { name: normalizer, priority: 9 }
   

   Why these priorities? We've been insisting that normalizers always have a comment explaining the rationale behind their priorities.

   (This is a huge weakness in the Symfony DIC — priorities should not be numerical; one should have to define before/after dependencies. Numerical priorities don't work in projects that can be extended by simply installing modules.)

3. +++ b/core/modules/layout_builder/src/Normalizer/LayoutSectionItemNormalizer.php
   @@ -0,0 +1,28 @@
   +class LayoutSectionItemNormalizer extends FieldItemNormalizer {
   ...
   +  protected $supportedInterfaceOrClass = LayoutSectionItem::class;
   

   Ideally we wouldn't have @FieldType-level normalizers.

   But it's indeed necessary for denormalization.

   Can you please make this service private and internal? So we can remove it when #2957385: FieldItemNormalizer never calls @DataType-level normalizer service' ::denormalize() method lands.

4. +++ b/core/modules/layout_builder/src/Normalizer/SectionDataNormalizer.php
   @@ -0,0 +1,45 @@
   +    return $object->getValue()->toArray();
   

   I'm a bit scared by how freeform this seems to be. If it's so freeform, how will https://www.drupal.org/project/openapi then be able to generate documentation for this?

5. In general: please look at #2926508: Add DateTimeNormalizer+TimestampNormalizer, deprecate TimestampItemNormalizer: @DataType-level normalizers are reusable by JSON:API for guidance/inspiration!
6. It'd be great to also manually test this in JSON API (I realize you can't add test coverage for it since JSON API is not in core).

+++ b/core/modules/layout_builder/src/Normalizer/SectionDataNormalizer.php
--- /dev/null
+++ b/core/modules/layout_builder/tests/src/Unit/SectionDataNormalizerTest.php

+++ b/core/modules/layout_builder/tests/src/Unit/SectionDataNormalizerTest.php
@@ -0,0 +1,86 @@
+namespace Drupal\Tests\layout_builder\Unit\Normalizer;

namespace mismatch; delete the \Normalizer part or move the file in and things should pass.

Great work!

1. +++ b/core/modules/layout_builder/src/Normalizer/LayoutSectionItemNormalizer.php
   @@ -0,0 +1,32 @@
   + * @todo Remove in https://www.drupal.org/node/issues/2957385
   

   ❤️

2. +++ b/core/modules/layout_builder/src/Normalizer/SectionDataNormalizer.php
   @@ -0,0 +1,45 @@
   +  protected $supportedInterfaceOrClass = SectionData::class;
   ...
   +    /** @var \Drupal\Core\Field\FieldItemInterface $field_item */
   

   This is tying the denormalization of a @DataType to its containing field. That shouldn't be necessary. All this should be doing is creating the value necessary to be set on the main property of a @FieldType=layout_section.

   Then LayoutSectionItemNormalizer::denormalize() can take that return value and set it on the @FieldType=layout_section target instance.

   Is this confusing, messy, and poorly delineated? Yes. That's what #2926507: Discourage @FieldType-level normalizers, encourage @DataType-level normalizers, to strengthen the API-First ecosystem aims to fix/standardize, but until then we need to be vigilant, to not introduce even more of these.

3. +++ b/core/modules/layout_builder/tests/src/Unit/SectionDataNormalizerTest.php
   @@ -0,0 +1,86 @@
   +class SectionDataNormalizerTest extends UnitTestCase {
   

   🤘

Based on #15, we need to fix .2 of that review.

I'm not sure I agree with #2914503: Determine if serializing blobs is safe for use in Layout Builder's outcome — if that had had a different outcome, then this issue may not have needed to exist.

Adding this as a stable blocker as sites need a way to export landing page content for deployment to other environments. This was possible with Lightning Landing Pages with Panelizer and is needed for nodes using Layout Builder with modules such as Default Content. Default Content exports are empty without this serializing patch.

Here is a reroll of #14 against the latest 8.6

Not sure if this is working for REST, but it's not working for default_content. This patch allows me to export a node with layout_builder and I see the proper json data in the export. However when I try to import the node json, I get:

In SqlContentEntityStorage.php line 783:

Value assigned to "section" is not a valid section

In SectionData.php line 31:

Value assigned to "section" is not a valid section

When debugging this, it's trying to assign an array to the "section" property rather than a Section object class. Doesn't seem like the denormalizer is being called in LayoutSectionItemNormalizer::denormalize. But maybe it hasn't gotten to that point yet since the debug stack shows it is trying to get the property value in order to determine if it's empty first.

Seems maybe related to this: https://www.drupal.org/project/jsonapi/issues/2955615 in JSONApi, but not fixed in core itself.

Edited: Looks like this is what @samuel.mortenson was saying in #17, so sorry for the dup.

Here is a tweak to the patch. This doesn't feel right at all, but it got me past the errors in default_content when importing the section json. default_content import is never calling anything in the SectionDataNormalizer so not sure if that's an issue with default_content or with the normalizer. Given that Sam mentioned he tested the previous patch with JSON get/patch it makes me think either default_content has a problem with json importing typed-data or that there is another core issue buried somewhere.

In any case, posting this patch so a client can try it and to get more comments.

#24: Yeah, it definitely doesn't seem right that LayoutSectionItemNormalizer::denormalize() is duplicating logic from SectionDataNormalizer::denormalize(). That almost must mean that default_content does something funky, like only denormalizing field-level data and not field property-level data.

Re-scanning this issue, I see that in #18 I linked to #2914503: Determine if serializing blobs is safe for use in Layout Builder. That reminds me of #2895532: @DataType=map cannot be normalized, affects @FieldType=link, @FieldType=map.

1. +++ b/core/modules/layout_builder/src/Normalizer/LayoutSectionItemNormalizer.php
   @@ -0,0 +1,32 @@
   +    $section_data = $this->serializer->denormalize($data['section'], SectionData::class, $format, $context);;
   +    return parent::denormalize($section_data->getValue(), $class, $format, $context);
   

   Let's add some docs here.

2. +++ b/core/modules/layout_builder/src/Plugin/DataType/SectionData.php
   @@ -27,6 +27,9 @@ class SectionData extends TypedData {
   +    if ($value && is_array($value)) {
   +      $value = Section::fromArray($value);
   +    }
   

   We should add dedicated test(maybe KTB) for this.

I applied patch from #24 to Drupal 8.6.4 and it works fine for me. I exported node with layout to default content and imported it back and all works fine.

The #24 also worked for me.

This just came up in the JSON:API issue queue: #3022575: [upstream] Support for layout 😀

#24 also worked for me, Drupal 8.6.5.

Tried #24 in 8.6.7 and it works as expected.

_{Sorry for the long silence on my side 😔 A proper deep dive below!}

👍 Normalization:

First, and most importantly: applying this patch makes it show up in the json and hal_json formats fore core's REST module, as well as for the contrib JSON:API module (soon to be in core: #2843147: Add JSON:API to core as a stable module). All information is available, and consistently so.

🙏 Normalization test coverage

This patch contains unit test coverage (👏), but not functional test coverage. Experience has taught me that for anything REST API-related, we want functional test coverage. Because there are so many subsystems being integrated (Entity API, Field API, Typed Data API, Routing API, Access API, Serialization API …), a functional test is a way to prove that it all actually works in actual requests.

#2942976: Add REST test coverage for Layout Builder already exists for this, but I think it should be merged with this. We already have examples of REST tests for specific field types: \Drupal\Tests\datetime\Functional\EntityResource\EntityTest\EntityTestDateonlyTest, \Drupal\Tests\entity_test\Functional\Rest\EntityTestTextItemNormalizerTest, and more.

🤔 Schema: documentation describing how to interpret the stored value

Second most important: being able to make sense of this data: what is its schema, what is the meaning of the structure, and each particular value?

Without this, it's going to be impossible difficult for decoupled applications to allow a content creator to customize each individual entity and have the client respect this custom layout.

Now, to be fair, Drupal 8.0.0 shipped without schema support for its REST API. I don't think we should hold Layout Builder to a higher standard. So I'm not arguing for complete/comprehensive API docs. I'm saying that for this field to be actually consumable/interpretable, given the complexity of a value for this field/data type is significantly higher than other core fields, it's necessary for it to be at least clearly documented. https://www.drupal.org/docs/8/core/modules/layout-builder does not yet exist.

#2919811: Write Layout Builder handbook documentation already exists for this.

😨 Validation

It seems that validation is currently limited to:

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

@mpotter encountered this in #23 when trying to use Layout Builder + https://www.drupal.org/project/default_content. Which is why he added the tweak/hack/work-around in #24.

This isn't "real" validation though: it's only verifying that it receives data of a certain type, it doesn't yet verify the values of that data.

I've searched through the code base, and as far as I can tell, validation is absent! 😨 To be more precise: there is no active need for validation logic, because the UI is structured in such a way that only trusted logic ever generates values to be stored. \Drupal\layout_builder\SectionListInterface + \Drupal\layout_builder\Section + \Drupal\layout_builder\SectionComponent fit together, forming a data structure that is more restricted than just an array, the UI/form logic interacts with methods on these, and hence there hasn't been a need for validation logic (at least not yet).

However, when a decoupled client wishes to modify the layout for an entity, it of course does not have access to these nice PHP interfaces — all it has is plain JSON. There is no validation constraint on either @FieldType=layout_section or @DataType=layout_section. Which means that I can set arbitrary data. This has at least two dangerous consequences:

1. I can break the site (or at least the viewing of a particular entity, and probably the editing of said entity too) by sending garbage data — AFAICT any array will be accepted.
2. I can disclose sensitive information, by for example placing a "View" block with sensitive information without further access control, whose access is intended to be protected through block visibility rules. Since there are no restrictions on which blocks I can place.

😨 Access

AFAICT currently anybody who can edit the entity, can also edit Layout Builder's field.

Considering the risks wrt validation, a viable strategy could be that only trusted users can modify Layout Builder's field. There is a configure any layout permission, but it's only applied to routes (with the _has_layout_section route requirement).

@FieldType=layout_section could be protected by this permission as well. Created #3028301: Do not expose to Layout Builder's sections either in defaults or overrides to REST and other external APIs for this.

🙏 Normalization implementation: complicated by the desire to support writes

The only reason that LayoutSectionItemNormalizer exists (at least until #2957385: FieldItemNormalizer never calls @DataType-level normalizer service' ::denormalize() method lands), and also the only reason that \Drupal\layout_builder\Plugin\DataType\SectionData needs to be modified, is to support writes. The patch would become much simpler if we chose to not support writing, for now. Most of the value is in reading it anyway!

Conclusion

I see the following paths forward:

1. The patch works well in that it exposes the data. But I worry that client developers will not know how to interpret this data.
   1. We could solve this altogether by simply not yet exposing this field via an API — that's totally legitimate! Once we make this available via APIs, we have to support it forever. Are we confident enough to commit to that? Marking this field type internal for now (see https://www.drupal.org/node/2916592) inaccessible (even better!) would instantly solve this issue.
      See 2942975-33_forbid_all_access.patch.
   2. If we don't want to do that, we have to document it and add explicit test coverage for at least one of every possible type of thing (field, block, view …) that can be placed using Layout Builder, to ensure we don't unknowingly change the schema. This is doable.
2. My biggest fear is letting API clients writing layout information. AFAICT validation is absent. Which is fine for the coupled UI because it naturally limits what data can be saved, but not for a decoupled UI. I've explained why this can easily lead to broken sites at minimum, and information disclosure at worst.
   1. I think we should remove the ability to set this field via the API, at least for now.
      See 2942975-33_forbid_write_access.patch.
   2. If that's not an option, then I think we should at least restrict access.
      See #3028301: Do not expose to Layout Builder's sections either in defaults or overrides to REST and other external APIs.

@Wim Leers thanks for the detailed review!

I can disclose sensitive information, by for example placing a "View" block with sensitive information without further access control, whose access is intended to be protected through block visibility rules. Since there are no restrictions on which blocks I can place.

I think this is similar to the block UI in that if you give the user administer blocks permission that can place any block. True the user could set a visibility rule for user role but they don't have to. So you are essentially giving them permission to place any block and have render whatever it will render.

At least in the layout case, for now, configure any layout, is a restricted permission.

So for a Layout user they can place any block regardless of whether they are doing so via the UI or through a REST call.

AFAICT currently anybody who can edit the entity, can also edit Layout Builder's field.

Yes this is true for except for the access control on the routes. With the route access control only users with configure any layout permission can edit layouts. They don't actually need access to update the entity(or view right now 😫#3028490: Users with "configure any layout" can see entities they don't have "view" access to)

The patch would become much simpler if we chose to not support writing, for now. Most of the value is in reading it anyway!

I 2nd this. I think a read-only solution now would be very useful.

Once we make this available via APIs, we have to support it forever. Are we confident enough to commit to that?

I would probably defer to @tim.plunkett on this. I guess 1 reason to not expose the field at all right now is I think we would be much more sure after 6 months or 1 year of Layout Builder being stable.

I think that if for some reason we need to change the way the field is stored we could do that without any BC implications if the field is not exposed via our APIs. Because the no module should ever deserializing the Layout reading the data.

If we expose the field over the API it would be effectively just that same as saying we support modules getting the json string decoding it and figuring out the layout from there. Because this is effectively be what a decoupled application would be doing.

And once we expose we can never change that structure. Though in theory we could write a BC layer to with normalizer to keep the format the same for sites that want it the same. But considering how much discussion there was around #2751325: All serialized values are strings, should be integers/booleans when appropriate and #2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX I think that is something we want to avoid at all costs if we can.

So that would lead me to endorse:

We could solve this altogether by simply not yet exposing this field via an API — that's totally legitimate! Once we make this available via APIs, we have to support it forever.

If we can't do that I think we should only allow read access for now.

I have repurposed the existing issue which was Add default field-level access restriction to Layout Builder's field type to #3028301: Do not expose to Layout Builder's sections either in defaults or overrides to REST and other external APIs

basically the idea is do this in 3 stages

1. No field API access
2. Read access
3. Write access

but we could discuss on that issue and leave this 1 for when we actually want to implement the normalizer(if we don't want to do it now)

Moving tag to other issue

#34:

I think this is similar to the block UI in that if you give the user administer blocks permission that can place any block.

If that were the case, I wouldn't be worried. But today, there's no access control on the layout field at all: if the entity can be edited, then the layout can be edited. Which you acknowledged further in your comment.

Thanks for linking #3028490: Users with "configure any layout" can see entities they don't have "view" access to — I hadn't found that yet. Following.

Marking this issue postponed on #3028301: Do not expose to Layout Builder's sections either in defaults or overrides to REST and other external APIs.

Turns out we had to introduce a hack in JSON:API itself to avoid exposing LB data over JSON:API. Adding #3040354: Introduce entity type annotation key for indicating that an entity type is *safe* for HTTP API usage as a related issue.

Since our existing normalizer for REST didn't apply to JSON:API, retitling to make it clear that fixing both should be in scope.

The only issue I recall is inline blocks which has no ui and not enough data exposed

@Wim Leers filed #3043245: Allow marking a config schema types to be marked as "internal" (to avoid exposing them via HTTP APIs).

Just curious whether any progress has been made here. Since both JSON:API and Layout Builder are stable in core I think people will expect them to play nicely together.

Also wondering what the current workaround for this is. The original patch in #24 was to provide a Json Normalizer for SectionData so the default_content module could export landing page nodes to be deployed across sites.

In the past, landing pages could be designed using Panels and Page Manager and exported to config and deployed across site environments. With Layout Builder, landing pages are Node content and the main way our clients deployed this content was via the default_content module. Now with 8.7 this has all broken and clients no longer have a way to deploy configured landing pages between environments (such as a search results page with facet blocks and other blocks placed on the page).

Is there any other way to restore a Json Normalizer that default_content can use to export a Node with Layout SectionData as JSON without exposing it to the world via Json:api?

@mpotter for a while this normalizers could be added to https://www.drupal.org/project/better_normalizers

Added duplicate issue from Default Content to related issues

I'm using 8.7.1, patch #33 doesn't work for me.
And patch #24 give following error.
Error: Maximum function nesting level of '256' reached, aborting! in Drupal::getContainer() (line 128 of /var/www/centara/docroot/core/lib/Drupal.php) #0 /var/www/centara/docroot/core/lib/Drupal.php(283): Drupal::getContainer() #1 ......

Both patches work for me neither in JSON API nor default content export.

@Sharique I haven't actually tested the patches yet myself, but the error you've noted is unrelated. See https://stackoverflow.com/questions/4293775/increasing-nesting-function-...

Is there any progress? At 8.7 version all patches are not working.

Like gundose stated.

The patches on this page don't work with 8.7.

I have applied the patch in #24 cleanly, however there is no layout in the exported landing page.

If i'm understanding all this correctly,
layouts aren't exposed to REST and other API's in drupal 8.7.* due to https://www.drupal.org/project/drupal/issues/3028301 which in turn means, default_content_deploy doesn't export it either. Even with the patches on the issue this comment refers to being applied.

Can anyone thing of a work around, even if temporally?

OK.. Work around.

I'm uploading this patch but I do not recommend that it be accepted into core.
It's just here for you to apply to D8.7 if you so choose as a work around.

If you apply patch 2942975-24.patch
along with 2942975-52.patch

You will be able to export the layout using
default content deploy

Due to https://www.drupal.org/project/drupal/issues/3028301 restricting exposure of layouts, I don't know yet what a correct solution to this
would be.

I think better to add normalizer to https://www.drupal.org/project/better_normalizers and create separate release for 8.7

This issue blocks layouts from being exportable by any module attempting that (default_content, content_sync among others). As most people from issue queues of these modules will end up here, I decided to write up the possible solution here.

If you really want to have this working on 8.7.x (and possibly 8.8.x), you would have to apply the attached patch. It's just workaround though, because it has some security implications mentioned by Wim Leers . But that's not enough, you also would have to write custom normalizers for Layout elements. It is what was attempted by #24 . There are more issues if you want to use this exporting capability to later import these nodes with layouts. For example exported references to revision ids of inline block contents in layouts configurations won't match with the real ones, so there is more logic required to get proper references on import. I managed to make it work for my use case, and assuming the attached patch has been applied - it can be done by contrib module.

Luke Nuke, there is a work around for exporting layouts that works now, without any patch by taking advantage of layout builder library module. https://www.drupal.org/project/layout_library

With this you can create a layout in the library, and then instead of adding a layout override on a node, you tell that node to use the layout from the library.. and then it all exports nicely.

Reworked patches from #52 for D8.7.5
As mentioned in #52 It is a temporary solution. I've created it for using it along with default content export.

I've created it for using it along with default content export.

Just be aware that by doing this, you're on your own. Layout Builder does not guarantee that those storage details will remain the same. So if they change, your default content exports will stop working.

Updated my previous patch #56 (I've missed several files).
The patch for D8.7.5 and use it on your own risk.

One more patch for D8.7.5 - still use it on your own risk.

Manually tested the patch (8.7.x HEAD) with default_content module and the exported node has the layout configuration and node-level override details (as below).

"layout_builder__layout": [
        {
            "section": {
                "layout_id": "layout_onecol",
                "layout_settings": [],
                "components": {
                    "b9d1b078-51c2-4918-a69b-5a4b58e3a947": {
                        "uuid": "b9d1b078-51c2-4918-a69b-5a4b58e3a947",
                        "region": "content",
                        "configuration": {
                            "id": "block_content:18853fa3-6af3-44a2-a14e-799af4e46910",
                            "label": "Working block",
                            "provider": "block_content",
                            "label_display": 0,
                            "status": true,
                            "info": "",
                            "view_mode": "full",
                            "context_mapping": []
                        },
                        "additional": [],
                        "weight": 1
                    }
                },
                "third_party_settings": []
            }
        }
]

Tested patch manually on Umami (8.7.8) and multilingual website I am working on (8.7.7). I can confirm that Default content exports layout builder configuration.

"layout_builder__layout": [
        {
            "section": {
                "layout_id": "layout_onecol",
                "layout_settings": [],
		"components": {
                    "7ac803f4-47bf-45c6-bfda-cd53baa6bf06": {
                        "uuid": "7ac803f4-47bf-45c6-bfda-cd53baa6bf06",
                        "region": "content",
                        "configuration": {
                            "label_display": "0",
                            "context_mapping": {
                                "entity": "layout_builder.entity"
                            },
                            "id": "extra_field_block:node:page_laybout_builder:>
                        },
                        "additional": [],
                        "weight": 0
                    },
                    "a2e569b1-224c-4e3a-9569-03d0db59f2f0": {
                        "uuid": "a2e569b1-224c-4e3a-9569-03d0db59f2f0",
                        "region": "content",
                        "configuration": {
                            "label_display": "0",
                            "context_mapping": {
                                "entity": "layout_builder.entity"
                            },
                            "id": "field_block:node:page_laybout_builder:body",
                            "formatter": {
                                "label": "hidden",
                                "type": "text_default",
                                "settings": [],
                                "third_party_settings": []
                            }
                        },                                   
                    "16c0a1b9-9fb5-4b5d-9f71-bc30c84d65bd": {                   
                        "uuid": "16c0a1b9-9fb5-4b5d-9f71-bc30c84d65bd",         
                        "region": "content",                                    
                        "configuration": {                                      
                            "id": "inline_block:basic",                         
                            "label": "reger",                                   
                            "provider": "layout_builder",                       
                            "label_display": "visible",                         
                            "view_mode": "full",                                
                            "block_revision_id": "7",                           
                            "block_serialized": null,                           
                            "context_mapping": []                               
                        },                                                      
                        "additional": [],                                       
                        "weight": 2                                             
                    }                                                           
                },                                                              
                "third_party_settings": []                                      
            }                                                                   
        }                                                                       
    ]   

The patch at #59 works well. I checked with JSON API output, and I am able to see the components there.
However I have a case, where I am not able to fetch the component content.

1. Added a new node, with layout builder enabled per node.
2. Added a new block type, text block.
3. Added a new block content of type, text block.
4. From Node, layout manager, add a new block of type text block and add a block that already exists.
5. In the JSON API output, we cannot access content of Block, added via layout builder.

Question 1 - If we are exposing components, inside the layout, how do we plan to get content of each component ? There are no self or related links, to help you fetch the content and meta data of the component.
Question 2 - If all of the above is true, are we saying that, we can only access content of the block, which are not create via Layout Builder ?

I also see that JSONAPI, wont allow you to access the content of a block which is not reusable. A non Reusable block is created, when you add a block via Layout builder. However, this is also being worked upon here 2999491

Output of my JSON API

{
  "fda2e964-4a5e-4203-81ff-09954d1fb919": {
    "uuid": "fda2e964-4a5e-4203-81ff-09954d1fb919",
    "region": "first",
    "configuration": {
      "id": "inline_block:text_block",
      "label": "Non Reusable Block",
      "provider": "layout_builder",
      "label_display": "visible",
      "view_mode": "full",
      "block_revision_id": "2",
      "block_serialized": null,
      "context_mapping": []
    },
    "additional": [],
    "weight": 0
  },
  "f21a9758-3abe-4c96-8c60-53496fd31e42": {
    "uuid": "f21a9758-3abe-4c96-8c60-53496fd31e42",
    "region": "second",
    "configuration": {
      "id": "block_content:6255d80f-07e4-455e-bd47-f7a37fa9cee0",
      "label": "Reusable Block",
      "provider": "block_content",
      "label_display": "visible",
      "status": true,
      "info": "",
      "view_mode": "full",
      "context_mapping": []
    },
    "additional": [],
    "weight": 0
  }
}

Hi @Vaibhav I was facing the same issue, I have been able to send block bundle and block uuid in json output. This patch has been tested against 8.9.x branch.
Attaching the patch for the same
Thanks

As the patch in #65 is incorrect, uploading the correct patch, with interdiff.

Hello,

Our website uses a fair number of custom landing pages built using the landing page content type and modified using the layout builder. What is the status of a patch for this issue?

Zach

What is the status of a patch for this issue?

Patch #59 works well.

Patch #67 works like a charm! tested in Drupal 8.8.1

I used #67, now can see the layout_builder__layout but how can I use jsonapi to PATCH the node to change the layout? Always get errors when tried to PATCH.

Re-rolling against 8.9.x (and works for 8.8.x as well).

@arthur.islamov could you provide interdiff?

Confirming #72 is still an issue with #75: When attempting to PATCH a layout_builder__layout field, I receive: "The current user is not allowed to PATCH the selected field (layout_builder__layout)." I receive the same error with POST, meaning I can't create a custom layout in a node (i.e., I can't create custom landing pages from JSON:API). That's my sole need - is this patch only for EXPOSING the data, or also for creating/updating that data?

Tried patch #78 and it works fine for export, but somehow $section_data->getValue() (in LayoutSectionItemNormalizer->denormalize()) produces an error when importing node with individual layout (using content_sync module):

Error: Call to undefined method Drupal\layout_builder\Section::getValue() in Drupal\layout_builder\Normalizer\LayoutSectionItemNormalizer->denormalize() (line 30 of /var/www/rtc.ccuptest.co.uk/web/core/modules/layout_builder/src/Normalizer/LayoutSectionItemNormalizer.php).

So to workaround it I've added a check if method exists, if not - then using $data['section'] instead works fine.
Maybe it's better to debug SectionData class, but I got no luck with this (in 15 min), maybe someone else can handle it. Or maybe it's related ot my drupal version - 8.8.4. Meanwhile we can go ahead with this patch.

I've ran some more tests and it turned out that patch above not working as expected. Hope it would be fixed in the next release.

The latest patch was rerolled

Fixed for latest patch

I have applied #82 patch

I just tested this on Drupal 8.8, with layout builder and it's working well with content sync to export my inline blocks!
Anything I can do to help get this commited?

Currently tested for drupal 8.5 works like a charm! Thank you!

EDIT: Thank you for the reply @adam3145 I was using the wrong patch version, I used version 73 and it worked.

I am on 8.8.2, I just put the file in the /web folder of my site, and ran the patch -p1

Successfully applied patch #82.

Does anyone else is getting this a duplicate "section" tag? This is generating an error whenever I try to import.

"layout_builder__layout": [
        {
            "section": {
                "section": {
                    "layout_id": "layout_onecol",
                    "layout_settings": {

Thanks!

I am not, do you have multiple sections on your export, as currently I only have 1 on all my pages.

No, just a single section containing 2 blocks (body and a form).

Actually yes I do have duplicate sections, however I don't seem to be getting an error when trying to import.

Are you using content sync?

This hopefully fixes some things.

removes a level of un-needed nesting and general cleanup.

Hopefully a few more things fixed. The remaining failures I think are more complicated then what time I have to give right now. I did some manual testing and remaining failing tests didn't fail manually (for me).

We have to remove the uuids as the keys for components since it causes XML serialization to fail. It isn't really needed any way, so I don't think that is an issue. See interdiff for how that looks in umami.

As #64 wrote there are important questions this patch doesn't address. Layout builder will and should be used mostly for one time blocks and custom landing pages. So far we get config of the layout but content is non fetchable.

I don’t know what you mean content not exposed. I am using this with the content sync module and all of my inline blocks content are exporting and working perfectly

I opened #3151275: referencedEntities should return referenced layout builder added entities earlier to day that might be moderately related.

@adam3145 sorry I didn't make it clear enough. So currently only "reusable" blocks can be fetched with JSON:API, those that dont have that option enabled have access restriction. There is this message "The current user is not allowed to GET the selected resource. Non-reusable blocks must set an access dependency for access control." that comes from getAccessCheckedResourceObject which gets access info from
web/core/modules/block_content/src/BlockContentAccessControlHandler.php and checkAccess which has this

    if ($entity->isReusable() === FALSE) {
      if (!$entity instanceof DependentAccessInterface) {
        throw new \LogicException("Non-reusable block entities must implement \Drupal\block_content\Access\DependentAccessInterface for access control.");
      }

meaning you won't be able to fetch with JSON API non-reusable blocks with current access checker in getAccessCheckedResourceObject.

Other problem we have is that JSON:API output is not really DX friendly, simplest example would be that we get this export for simple custom block

                "uuid": "365dd4c2-41ad-469a-94b3-dc426e8587d0",
                "region": "content",
                "configuration": {
                  "id": "inline_block:hero_block",

which you then need to substring to get proper endpoint which would be jsonapi/block_content/hero_block/365dd4c2-41ad-469a-94b3-dc426e8587d0. This looks more like hardcoding stuff then dynamically getting proper endpoints.

And this is simple example. I have much more complex, like having ID from commerce block

         "uuid": "60bf2ad0-4fcc-4633-ba40-80b1a6829979",
                "region": "second",
                "configuration": {
                  "id": "field_block:commerce_product:toys:variations",

How to get proper url for this one :) is it even obtainable in current setup. There is some UUID but which endpoint to use here, JSON output doesnt help much?

#70 removed the issue summary, not sure why.
Restoring what it was, but I think it needs an update anyway.

#106: This means there will never be access for those one-shot blocks on their own.
I suppose Includes come to the rescue, and maybe #105.

That’s interesting. I am using content sync and my non reusable inline blocks are exporting perfectly. I think I am using patch from 82 or so.

I am using patch #78 as this is last one that works with 8.8.6 but I don't see this worked on on later patches and mentioned in comments and interfdiffs. If someone can verify this has been worked on later and where, would gladly check it.

Also if you are using revisions for your LB and blocks also have revisions you will probably have problems with jsonapi and UUIDs. Seems to me this is the problem https://www.drupal.org/project/drupal/issues/3043321 which leads to this
https://www.drupal.org/project/drupal/issues/3031271

For me block uuids in LB json object dont match what I can fetch, when exposing them they return nothing, but I can manually find proper versions that JA can expose.

I have made a module that automatically fixes the UUID's for the purposes of content sync with exposed inline blocks. I can share it here if that's helpfull, it is a stand alone module that I was going to post while this is fixed up in core...

I ran into an issue recently when exporting the layout builder data on a node that the inline blocks are linked via bid/vid. I can't just use their UUID and it relinks them when re-importing the content. That seems related to #112/113, is that true?

So I have a module that i did to fix that, It's attached. You just import normally then run this drush command to clean it up. "drush content-sync-fixer:all"

What we had to do is:

Layout Builder adds a new field to the tables where this feature is enabled, this field is a BLOB field where the layout configuration is saved as a PHP serialized object, each object in the layout is stored in this field with all the proper data to be shown, but, Layout Builder doesn't work as a Drupal entity itself it works in the same way as a text in a field.

Content Sync converts any content in a config presentation in YML when it is exported and then each file is interpreted in a reverse way. Content Sync creates blocks normally when it imports the content, but the relationship stored in the BLOB field is not processed to try to connect properly the content of the field with the blocks. Then the revision_ids inside each inline-block in the layout configuration could not match with the revision_ids over the imported blocks, this is why some inline-blocks are missed and others are misconnected.

To follow up the issue you must query the database in both instances (origin and destination) and check the related data to known entities and fields.

To get specific node information
SELECT * FROM node_field_data WHERE title = 'Web Design';

To get layout builder data using previous information
SELECT bundle, deleted, entity_id, revision_id FROM node__layout_builder__layout WHERE entity_id = 7;

To get serialized data
SELECT CAST(layout_builder__layout_section AS CHAR(50000) CHARACTER SET utf8) FROM node__layout_builder__layout WHERE entity_id = 7;

You will get some like this...
image.png

If you check the layout builder information with the block_content table in both instances (origin and destination), you could check that the information is the same (after import in destination)

But, if you check specific block using
SELECT * FROM block_content WHERE revision_id = 107;

It is possible that block content doesn't match, se below images
image.png

Our solution processes the content inside each node__layout_builder__layout record to connect each inline-block stored in the BLOB field taking in count its UUID code to connect to the correct block.

I'm currently using latest patch and noticed, that new options have been added to the configuration, but no corresponding schema. Attaching patch with added schema changes.

I've been testing this with latest patch in #116. TLDR, it works.

Now, the long answer, in case it helps anyone else.

Use case: Drupal as a repository of content for a js application (react, but could be vuejs or anything else).

Layout builder is needed to build the content and expose it via json. A content type with layout builder enabled and a few custom blocks for testing.

Used:

- Drupal Version 8.9.2
- https://www.drupal.org/project/jsonapi_explorer (for testing and exploration purposes)

New brand install, enabled json api and layout builder, left everything else untouched. From there, I created a few landing pages where I am overriding the layout, adding new columns, adding blocks, custom blocks with specific fields, etc…

I am fetching the whole list of nodes with this query:
http://alexplayground.lndo.site:8000/jsonapi/node/landing_page/

Then, once I know the node that I to check out, I just fetch that one, say for example:

http://alexplayground.lndo.site:8000/jsonapi/node/landing_page/?filter[d...

Results:
Without the patch I could not see any information related to the layout or the fields exposed on that layout.

After that, I applied the path and I repeated the query. Then I could see how a new field comes available: layout_builder__layout

On it I can see the different layouts, the components I have created inside those layouts, layout_id, column_widths, the weight of each component, etc.

Something to notice is that there will be no information on that query regarding the fields contained on those blocks, apart of label, uuid, and a few other bits. See:

  "configuration": {
        "id": "inline_block:custom_block",
        "label": "test title",
        "provider": "layout_builder",
        "label_display": 0,
        "view_mode": "full",
        "block_revision_id": "6",
        "block_serialized": null,
        "context_mapping": [],
        "type": "custom_block",
        "uuid": "3370b3b9-7d02-43b7-8b65-4c38de8dbf2d"
      },

This can be puzzling on the beginning if you are not familiar with json, and make you think that you are missing information on that query. However, and please correct me here if I'm wrong, I think this is expected. Those extra bits require an extra jsonapi call using the uuid that is provided. For example, I have several blocks on that payload. I choose one of them, get the uuid and make a query like this:

http://alexplayground.lndo.site:8000/jsonapi/block_content/text/d49bdb94...

@alexmoreno #117:

Great writeup!

> Something to notice is that there will be no information on that query regarding the fields contained on those blocks, apart of label, uuid, and a few other bits.
> This can be puzzling on the beginning if you are not familiar with json, and make you think that you are missing information on that query. However, and please correct me here if I'm wrong, I think this is expected. Those extra bits require an extra jsonapi call using the uuid that is provided.

Can you check if Includes do work for this case?

Thank you for explaining things well @alexmoreno. I had same issue (https://www.drupal.org/project/drupal/issues/2942975#comment-13341530), and hence added type and UUID fields to be output (https://www.drupal.org/project/drupal/issues/2942975#comment-13361683). This lets me atleast build the JSON:API URL, which I can use to fetch the content of the components placed, via layout builder.
Yes, this was tested well with custom blocks and multiple block type, however never tried with fields from node or any other blocks from contrib modules.

IMO, we should be providing the relative link automatically, so that we can hit one specific key to fetch the content, than building a URL currently.

@geek-merlin I have verified this before, JSON:API includes does not work well here. Hence the route of adding more info to the output was taken.

> I have verified this before, JSON:API includes does not work well here.

Interesting. We should understand and document why. Or even better, make this work, maybe in a followup.

@geek-merlin what I can see is that the document specifies that you need to use "relationship", ie:

{
  "data": {
    "type": "node--article",
    "id": "some-random-uuid",
    "relationships": {
      "field_comments": {
        "links": {
          "related": {
            "href": "https://my.example.com/node/article/some-random-uuid/field_comments"
          }
        }
      }
    }
  }
}

then you can make a query like this:

/jsonapi/node/article/some-random-uuid?include=field_comments.uid

where field_comments is specified on the relationships.

However on my tests I would not get those relationship fields, at least not for the layout builder components. I may not be doing it right though, see payload attached for reference.

https://www.drupal.org/files/issues/2020-07-17/response-layout-builder-p...

@alexmoreno: Thanks a lot!

I did not check the source how JsonApi populates that reference field, but the hottest guess is that it uses EntityInterface::referencedEntities. In which case fixing this at least needs the referenced issue (it may or may not need more).

Any news so far? This functionality is pretty essential for decoupled Drupal.
Is https://www.drupal.org/project/drupal/issues/3151275 a blocker?
Can we have this patch released at least as experemental module?

Hi again,

I have found an scenario where this is not working. I don't think it's expected, but please keep me humble here

If you override the node with a custom layout, the layout data is exposed correctly (as shown in #117).

However, if you have a default layout, and you don't override it in your node with the aim for that node to use the default one, then the json returns that the layout is empty. See:

```"layout_builder__layout":[]}```

When selecting as well that

Another case, if you specify that you don't want for that content type to be customised by the user on the node level, then the layout_builder__layout does not even appear on the json data.

Does this even make sense? Anyone could raise any light on this?

Thanks.

re #124

Does this even make sense? Anyone could raise any light on this?

Yes it makes sense. This issue just deals with exposing the stored layout information. Layout Builder stores the layout override data in a field it controls layout_builder__layout. It stores the default layout in the third party settings information of the LayoutBuilderEntityViewDisplay entity. If a particular bundle does not allow overrides then it does not create the layout_builder__layout field for that bundle.

It sounds like what you want is "For any entity using the layout builder give me layout information". This would take more custom code either on the client side making more request or server-side augmenting the data that is stored with the entity when it is returned with JSON API.

However, if you have a default layout, and you don't override it in your node with the aim for that node to use the default one, then the json returns that the layout is empty.

Yes this because when you make a JSON API request for the node it only returns the actual data that is stored in the field just like any other field. In the case when there is not an override there is not date stored in this field.

Another case, if you specify that you don't want for that content type to be customised by the user on the node level, then the layout_builder__layout does not even appear on the json data.

This is because the layout_builder__layout is not added until entity display is set to use the layout builder and allow overrides. The field is also deleted if the ability do overrides is removed(you can't do this while there is field data, i.e. any existing overrides.)
@see \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::addSectionField() and \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::removeSectionField()

if you wanted get the default layout when there is no override you would have to make a JSON API request for entity_view_display entity that stores this information in it's third party settings. It would tell if the layout builder is enable and the default layout.

I did some work trying to get the default layouts for when the nodes are not overriding it.

Here are my notes, I'll publish this code in a module as well, so it's easier to patch in case anyone has any feedback

https://www.alexmoreno.net/layout-builder-exposing-content-type-default-...

see as well the code here: https://www.drupal.org/project/lb_default_layout

Can we assume that this patch is tested and RBTC? Are there any concerns left?

Still needs an issue summary update.
The patch is also failing tests.
Here's a code review.
Whoever updates the patch, please include an interdiff.

1. +++ b/core/modules/layout_builder/layout_builder.services.yml
   @@ -44,6 +44,17 @@ services:
   +  layout_builder.normalizer.entity_display:
   +    class: Drupal\layout_builder\Normalizer\LayoutEntityDisplayNormalizer
   +    tags:
   +      # Priority must be higher than serializer.normalizer.config_entity.
   +      - { name: normalizer, priority: 1 }
   +    arguments: ['@entity_type.manager', '@entity_type.repository', '@entity_field.manager']
   +  layout_builder.normalizer.section_data:
   +    class: Drupal\layout_builder\Normalizer\SectionDataNormalizer
   +    tags:
   +      # Priority must be higher than serializer.normalizer.typed_data.
   +      - { name: normalizer, priority: 1 }
   
   +++ b/core/modules/layout_builder/src/LayoutBuilderServiceProvider.php
   @@ -39,14 +37,6 @@ public function register(ContainerBuilder $container) {
   -    if (isset($modules['serialization'])) {
   -      $definition = (new ChildDefinition('serializer.normalizer.config_entity'))
   -        ->setClass(LayoutEntityDisplayNormalizer::class)
   -        // Ensure that this normalizer takes precedence for Layout Builder data
   -        // over the generic serializer.normalizer.config_entity.
   -        ->addTag('normalizer', ['priority' => 5]);
   -      $container->setDefinition('layout_builder.normalizer.layout_entity_display', $definition);
   -    }
   

   Why this change?

2. +++ b/core/modules/layout_builder/src/Plugin/DataType/SectionData.php
   @@ -30,8 +30,18 @@ class SectionData extends TypedData {
   +
   +    if ($value && is_array($value)) {
   +      $value = Section::fromArray($value);
   +    }
   ...
        if ($value && !$value instanceof Section) {
   

   This addition isn't documented. It also seems to overlap with the next conditional

3. +++ b/core/modules/layout_builder/src/Plugin/DataType/SectionData.php
   @@ -30,8 +30,18 @@ class SectionData extends TypedData {
   +      else {
   +        parent::setValue($value->value, $notify);
   +      }
   

   Drop the else case, and have $value = $value->value;?

   Also why is there all of a sudden a $value->value?

4. +++ b/core/modules/layout_builder/src/Section.php
   @@ -337,9 +337,9 @@ public function toArray() {
   -      'components' => array_map(function (SectionComponent $component) {
   +      'components' => array_values(array_map(function (SectionComponent $component) {
   

   Why this addition? Does this change have test coverage?

5. +++ b/core/modules/layout_builder/tests/src/Unit/SectionDataNormalizerTest.php
   @@ -0,0 +1,95 @@
   +    $section->toArray()
   +      ->willReturn($data);
   +    $section_data->getValue()
   +      ->willReturn($section);
   

   Nit: remove needless returns/indents

6. +++ b/core/profiles/demo_umami/config/install/core.entity_view_display.node.recipe.full.yml
   @@ -31,7 +31,7 @@ third_party_settings:
   -          eadd557c-6414-40e5-9a95-355720385477:
   +          -
   

   Whoa, this is a data model change, isn't it?

re #128.6. See #100 for the reason for those changes. It was an issue w/ XML seralization. Not so much for JSON/YAML. But we have to support all, right?

Based on #116 patch, no changes, just want to patch successfully on Drupal 8.8.10

Added patch for 8.9.x, Kindly Review.

Ref from duplicate issue: https://www.drupal.org/project/drupal/issues/3182960

@mayurjadhav How does that relate to the patch from #116 that I reviewed in #128?
Or the reroll for 8.8 in #131? Your patch is less than half the size, and doesn't seem to have any test coverage.

As I asked in #128:

Whoever updates the patch, please include an interdiff.

Someone please help get this issue back on track! Needs an issue summary update, and also a fresh 9.2.x patch that takes #128 into account.

@tim.plunkett Sorry for the incomplete patch...I was in rush and uploaded patch without reading all comments..I'm working on latest patch which will address all the points mention in #128 along with Test.

#131 just for the 8.9.x branch

Hello Team

I have resolved phpcs for 9.1.x and added patch: 2942975_137.patch by combining 2942975-drupal_8_9_x-136.patch.

I have followed below steps for 9.1.x version:

• git clone --branch '9.1.x' https://git.drupalcode.org/project/drupal.git d
• Installed required modules for testing
• Enabled layout builder module for Article node and added custom block of that in Layout Builder
• After that, Accessed the added content using jsonapi: http://localhost/d/jsonapi/node/article/cebda01b-fd65-435f-a25a-25841dcd...
• Capture images before and after applying patch to this module
• We are able to see Layout Builder Details in the After Applying Patch.png

Please do check attached images for the reference.

Hello Team,

I have corrected CSpell : failed issue of https://www.drupal.org/pift-ci-job/2105852 for #138. Please do check updated patch (
2942975_140.patch, 2942975_d8_to_d9_140.patch ) for resolving the phpcs errors in Drupal 9.1.x.

Please merge #136 and create 3.x version, after that for 9.1.x, please merge
2942975_140.patch.

2942975_d8_to_d9_140.patch created for Unix Line Ending formats and root directory is in /app folder.

@kuhikar please add interdiff

Hello Team,

Please do check updated patch : 2942975-142-d8_d9.patch for resolving hunk error.

@dmitry.korhov, Please check attached interdiff-136-142.txt.

I have applied #136 patch on D89x and #142 on D91x and after that, I run command to get diff for --core/modules/layout_builder.

Hello Team,

Currently, we are migrating D8 to D9 and please help to merge patch so we will have 3.x version.

Please do check: Drupal 8 end-of-life on November 2, 2021 : https://www.drupal.org/psa-2021-2021-06-29

Kindly help us to release 3.x version.

Hello Team,

Any update to release 3.x version of this module? Kindly help us.
@dmitry.korhov, Can you please review patch: 2942975-142-d8_d9.patch

Drupal 8 end-of-life on November 2, 2021 : https://www.drupal.org/psa-2021-2021-06-29

I re-rolled this against 9.3.x

Unfortunately all of the patches posted since #116 have either lost changes or added new unnecessary changes. Switching to an MR and maybe going to try to address #128...

Still needs an issue summary update.

NR to see how tests are doing

Okay I went ahead and made the issue summary updates and feedback changes I'd asked for last year, and resolved the remaining test failures.
This should be ready for review now.

Commit e866ee63 is causing a fault on my system:

[error] InvalidArgumentException: Value assigned to "section" is not a valid section in Drupal\layout_builder\Plugin\DataType\SectionData->setValue() (line 34 of /app/docroot/core/modules/layout_builder/src/Plugin/DataType/SectionData.php).

$value is still being passed in as an array for a custom layout section, removing the array filter from SectionData::setValue() causes it to break.

Here's a patch based on MR 1131 and the comment #150.

Something went wrong.

I ran the failing tests multiple times locally. The result toggles. Sometimes the tests succeed, sometimes they fail.

Please stop posting patches now that we're using the MR. Just push new commits to the branch.

@tim.plunkett the patch I posted didn't contain anything new. It just reflects an earlier version of the MR, that doesn't lead to errors in default_content_deploy, just as mentioned in #150.
I uploaded it to have something that could be used deployment piplines already.

Am I allowed to revert your change directly in the MR?

The required change is already discussed above and it seemed that you're not convinced yet.

I can confirm that the patch from #152 works with Tome and JSON:API whereas the current MR works with JSON:API but not Tome, with the errors reported in #150.

It would be ideal to get the MR synced back to the patch.

Rebased a patch #152 to merge with Drupal 9.3.x branch.

Hi all, I try to solve the puzzle to load layout builder inline blocks with JSON:API. My puzzle starts here and after a long weekend I just want to ask if I am on the right trail.

This patch provides sections and components but not the associated block content entities. This is by design. To fetch inline blocks we need a second jsonapi call. @alexmoreno mentioned it in #117. (Thanks for the post, it helps to understand such long issues)

Fetching blocks works right now BUT filter by any query doesn't. There is hard coded resuable=true in TemporaryQueryGuard. So I can't fetch them. This is propably also by design? So I can fetch a block with jsonapi/block_content/text/d49bdb94... but not with jsonapi/block_content/text?filter[id]=d49bdb94... or with any other filter.

        if (isset(static::$fieldManager->getBaseFieldDefinitions($entity_type_id)['reusable'])) {
          $specific_condition = new EntityCondition('reusable', 1);
          $cacheability->addCacheTags($entity_type->getListCacheTags());
        }

So I did not find any solution to fetch multiple non reusable inline blocks in one call. To help me out I created https://www.drupal.org/project/jsonapi_include_lb which uses a simple computed field to provide blocks as entity reference.

Is there a better option?

Re-rolled against 9.4.x to get test results

I ran the tests locally. The same tests fail. As soon as I enable xdebug and step through \Drupal\rest\Plugin\rest\resource\EntityRessource::get(), the tests succeed. It looks like a timing issue which is strange.
If the error happens and the server returns status code 500 it complains about an illegal character in \Symfony\Component\Serializer\Encoder\XmlEncoder.
But I can't debug it. As already mentioned, the error doesn't happen as soon as xdebug is enabled and I try to step through the process.

re-rolled against 9.4.x after conflict caused by commit of #3252872: Use CacheableSupportsMethodInterface for performance improvement in normalizers

like described in #165 and seen as different numbers of failures in #163 and #166, there seems to be a timing problem or an issue with randomized content in the tests.

I am confused why we went away from this approach which return components as an array of objects: https://www.drupal.org/files/issues/2021-08-25/2942975_145.patch

This is much more useful in Gatsby. I saw at some point that change went away back to a nested object.

I have the same issue cited in https://www.drupal.org/project/drupal/issues/2942975#comment-13361683 and other places where I can't fetch inline block data from JSON:API like I would say paragraphs. Those JSON:API endpoints only include reusable blocks and the patch from this thread does not include all the block fields in layout_builder__layout. That means I am unable to get all the block data I need on the frontend.

After quite a bit of work/testing I found the solution I needed in project jsonapi_include_lb.

I rebased the MR with 9.4.x branch. I am not able to edit the base branch in the MR. I am not sure if I need any permission for that.

@tim.plunkett can you please update that?

I continued testing the MR on my local. I see two tests are failing which are because of a single reason. The xml format is not rendering properly. The error is following:

DOMException: Invalid Character Error in DOMDocument->createElement() (line 490 of /app/vendor/symfony/serializer/Encoder/XmlEncoder.php).

The reason is the uuid part inside the component key.

"components": {
   "38a9bdec-3df6-457d-bf7a-15b19bd67736": {
}

Does anybody have a suggestion on this problem?

Paragraph does it like this and it works fine with paragraph:

"field_test": [
	{
		"target_id": 1,
		"target_revision_id": 1,
		"target_type": "paragraph",
		"target_uuid": "d1fd68e4-e561-4d09-afd4-cbb6ac86d190"
	},
	{
		"target_id": 2,
		"target_revision_id": 2,
		"target_type": "paragraph",
		"target_uuid": "02b5f3d6-8cf5-4b31-9b07-cb5480223860"
	}
]

#173, thanks for the rebase. I adjusted the target branch.

I have given this MR a try today and found that while it did expose the Layout Builder data, it unfortunately didn't do a great job exposing data for the inline_block entities.

Within each Layout Builder Section these block are referenced with block_revision_id, but the relationships are not attached to allow modules like entity_share to know where to find these.

It would be ideal if these could be looked up and appended in a similar method to EntityReference fields. I did take a look at updating the MR with this myself, but it looked a little too complex to attempt without guidance.

From what I understand, it would involve updating ResourceObjectNormalizer::serializeField() to handle LayoutSectionItemList fields, along with adding quite a few new methods (e.g. Relationship::createFromLayoutBuilderField()) to find and append the correct relationships.

      if ($field instanceof EntityReferenceFieldItemListInterface) {
        // Build the relationship object based on the entity reference and
        // normalize that object instead.
        assert(!empty($context['resource_object']) && $context['resource_object'] instanceof ResourceObject);
        $resource_object = $context['resource_object'];
        $relationship = Relationship::createFromEntityReferenceField($resource_object, $field);
        $normalized_field = $this->serializer->normalize($relationship, $format, $context);
      }
      else if ($field instanceof LayoutSectionItemList) {
        // Pluck inline_block revision IDs and append to relationships here
      }
      else {
        $normalized_field = $this->serializer->normalize($field, $format, $context);
      }

{
  "jsonapi": {
    "version": "1.0",
    "meta": {
      "links": {
        "self": {
          "href": "http://jsonapi.org/format/1.0/"
        }
      }
    }
  },
  "data": {
    "type": "node--article",
    "id": "d7284b3e-a616-4d33-ac88-919bce701b63",
    "links": {
      "self": {
        "href": "https://dev.example.com/jsonapi/node/article/d7284b3e-a616-4d33-ac88-919bce701b63?resourceVersion=id%3A1"
      }
    },
    "attributes": {
      "drupal_internal__nid": 1,
      "drupal_internal__vid": 1,
      "langcode": "en",
      "revision_timestamp": "2021-09-14T09:41:50+00:00",
      "revision_log": null,
      "status": true,
      "title": "Article Style Guide",
      "created": "2021-09-14T09:41:39+00:00",
      "changed": "2022-01-19T10:47:02+00:00",
      "promote": false,
      "sticky": false,
      "default_langcode": true,
      "revision_translation_affected": true,
      "metatag": null,
      "path": {
        "alias": "/article-style-guide",
        "pid": 82,
        "langcode": "en"
      },

      ...

      "layout_builder__layout": [
        {
          "section": {
            "layout_id": "layout_twocol_section",
            "layout_settings": {
              "label": "",
              "column_widths": "50-50",
              "layout_builder_styles_style": [
                "section_margin_normal",
                "section_vertical_align_top",
                "section_width_normal"
              ],
              "context_mapping": []
            },
            "components": {
              "5a6eed43-01f1-4bc3-88d3-0e933da4ab7e": {
                "uuid": "5a6eed43-01f1-4bc3-88d3-0e933da4ab7e",
                "region": "first",
                "configuration": {
                  "id": "inline_block:image",
                  "label": "",
                  "label_display": true,
                  "provider": "layout_builder",
                  "view_mode": "full",
                  "block_revision_id": "223987",
                  "block_serialized": null,
                  "context_mapping": []
                },
                "weight": 0,
                "additional": []
              }
            }
          }
        }
      ]
    },
    "relationships": {
      "node_type": {
        "data": {
          "type": "node_type--node_type",
          "id": "1af93c9b-8669-4535-b786-f4c3f0b51488",
          "meta": {
            "drupal_internal__target_id": "article"
          }
        },
        "links": {
          "related": {
            "href": "https://dev.example.com/jsonapi/node/article/d7284b3e-a616-4d33-ac88-919bce701b63/node_type?resourceVersion=id%3A1"
          },
          "self": {
            "href": "https://dev.example.com/jsonapi/node/article/d7284b3e-a616-4d33-ac88-919bce701b63/relationships/node_type?resourceVersion=id%3A1"
          }
        }
      },

       // Would be ideal to see the related inline_block entities here!!

    }
  },
  "links": {
    "self": {
      "href": "https://dev.example.com/jsonapi/node/article/d7284b3e-a616-4d33-ac88-919bce701b63?resourceVersion=id%3A1"
    }
  }
}

re #176

It would be ideal if these could be looked up and appended in a similar method to EntityReference fields.

I agree what that would be ideal but I think that could be follow-up to this issue. This issue is already 4 years old and adding more scope will just make take longer to get committed.

I don't think we can alter layout_builder__layout to add this information because then this would probably cause problems for instance where this serialization was being used for import/export purposes. So it would probably have to be somewhere else in the JSON API response. For that reason I think it adds extra complexity to this issue.

This patch is for core 8.3.x and contains array_values for SectionComponent. To avoid to crash the installation.

Patch for core 9.3.x (posted in #178) was updated:
Added exposing of sections on request (through jsonapi module /jsonapi/page_variant/page_variant) of page variant which was built as a "Layout Builder". See more details here: https://www.drupal.org/project/page_manager/issues/3170526

@tim.plunkett or @joachim is it possible to add changes:

diff -u b/core/modules/layout_builder/src/Section.php b/core/modules/layout_builder/src/Section.php
--- b/core/modules/layout_builder/src/Section.php
+++ b/core/modules/layout_builder/src/Section.php
@@ -16,7 +16,7 @@
  * @see \Drupal\Core\Layout\LayoutDefinition
  * @see \Drupal\layout_builder\SectionComponent
  */
-class Section implements ThirdPartySettingsInterface {
+class Section implements ThirdPartySettingsInterface, \JsonSerializable {
 
   /**
    * The layout plugin ID.
@@ -441,2 +441,11 @@
 
+  /**
+   * Returns a representation of the section for use in JSON serialization.
+   *
+   * @return array
+   *   Representation of the section.
+   */
+  public function jsonSerialize() {
+    return $this->toArray();
+  }
+
 }

to the issue branch (to be able to export of sections through the jsonapi module on request like /jsonapi/page_variant/page_variant).

UPD: Added, found how to do it by myself. Sorry for bothering.

Still needs to fix, test issues.

[Deleted] My comment is about the layout_builder_st contrib module, not core. Apologies for getting my wires crossed. I'll go make my comment there.