🇬🇧United Kingdom @alexmoreno

gusaus → credited alexmoreno → .

Just to say that this is super helpful and insightful, thanks for keeping this list @mindaugasd

nicxvan → credited alexmoreno → .

should this be closed as obsolete as per #46 and #47 @larowlan @kim.pepper ?

alexmoreno → created an issue.

this contains information about running the scripts, but I'll add it to the Readme asap, so it's more accessible to anyone trying to extract any kind of information from d.o

https://docs.google.com/document/d/1y8hr7rHO-QqyUlSVr2V2h7UY7tV3-ucoD45z...

This should give you access to the sandbox:

• https://www.drupal.org/drupalorg/docs/build/development-environments/dev → ...
• Use these drush scripts to extract the information you need (csv format): https://github.com/alex-moreno/health-contribution-dashboards

gusaus → credited alexmoreno → .

gusaus → credited alexmoreno → .

gusaus → credited alexmoreno → .

alexmoreno → created an issue.

Paul, my friend. Your experience and knowledge is always welcomed, and your feedback greatly appreciated. Those are great points :-D

Thanks a lot for taking the time to write this :-)

alexmoreno → created an issue.

gusaus → credited alexmoreno → .

xjm → credited alexmoreno → .

brianperry → credited alexmoreno → .

This is actually an issue in the docs. You will hit this problem as well doing for example a drush uli in php 7.4:

ddev drush uli
 [error]  ParseError: syntax error, unexpected '|', expecting ';' or '{' in Composer\Autoload\{closure}() (line 37 of /var/www/html/web/modules/contrib/tome/modules/tome_sync/src/Normalizer/EntityReferenceRevisionItemNormalizer.php) #0 /var/www/html/vendor/composer/ClassLoader.php(427): Composer\Autoload\{closure}('/var/www/html/w...')

alexmoreno → created an issue.

brianperry → credited alexmoreno → .

brianperry → credited alexmoreno → .

brianperry → credited alexmoreno → .

alexmoreno → created an issue.

alexmoreno → created an issue.

Congratulations Lauri 👏

alexmoreno → created an issue.

Amazing, thanks all :-)

alexmoreno → created an issue.

Zoocha Will → credited alexmoreno → .

volkswagenchick → credited alexmoreno → .

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?

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-...

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.

@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... →

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...