Create HTTP Endpoint for View modes/content templates

My preference would be the first way (not flat). And yes the frontend can construct the 'layout_url' => '/xb/api/v0/layout-template/node/page/full/ given the response.

$view_modes = [
      'node' => [
        'page' => [
          'full' => [
            // Whether template has auto-save changes. This can be tru even if
            // existing_template is false since we auto-save templates before
            // first publishing without creating a new saved template.
            'auto-save-changes' => TRUE,
            // Where the there is an existing template saved.
            'existing_template' => TRUE,
            // The ID does require an exisitng template because it is based on
            // entity props that can't be changed.
            'template_id' => 'node.page.full',
          ]
          'teaser' => [
            'auto-save-changes' => FALSE,
            'existing_template' => FALSE,
            'template_id' => 'node.teaser.full',
          ]
        ]
        'article' => [
          'full' => [
            'auto-save-changes' => FALSE,
            'existing_template' => TRUE,
            'template_id' => 'node.article.page',
          ]
          'teaser' => [
            'auto-save-changes' => TRUE,
            'existing_template' => TRUE,
            'template_id' => 'node.article.teaser',
          ]
        ]
      ],
    ];

The issue summary already talks about nodes only, but I just wanted to reinforce that at this stage we're only targeting node bundles, no other entity types are in scope.

The issue summary already talks about nodes only, but I just wanted to reinforce that at this stage we're only targeting node bundles, no other entity types are in scope.

FYI this is enforced since https://git.drupalcode.org/project/experience_builder/-/commit/843e7b0b1...

Please follow the patterns set in 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active :

• add new method to ApiUiContentTemplateControllers
• add success test coverage + comprehensive client error test coverage ApiUiContentTemplateControllersTest
• expand OpenAPI spec

Mentioned this on a call but just want to record here, can the view mode response can also provide a key with the first available node entity that the frontend can use to display the template with? And if a content of that bundle doesn't exist yet then it can be null or something and the frontend can handle accordingly to maybe show an warning message in the UI to require a user to create content for it if they want to view the template for that bundle in XB.

I've had a chat with @hooroomoo about this and we most likely will need two or three separate endpoints:

1. Endpoint that provides a list of Template entities, grouped by entity type and bundle
2. Endpoint that provides a complete list of existing Drupal view modes
3. Endpoint that provides a list of Drupal view modes for specific combination of entity type and bundle

Current MR only adds #1 and is not complete, but it might be decent place to start for FE work until we complete rename process.

currently creating another MR for canvas

Got new MR https://git.drupalcode.org/project/canvas/-/merge_requests/10 almost passing

assigning it back to @wimleers because @f.mazeikis had assigned to him

Few more things to do after yesterdays conversations, assigning to myself

Well, I started a review already anyway, and I think I found one seemingly quite big problem 😅

Plus, I don't see why this is unable to use the existing infrastructure we've carefully grown to avoid duplication and improve maintainability: why can't this use CanvasHttpApiEligibleConfigEntityInterface?

Details on the MR.

f.mazeikis → changed the visibility of the branch 3541015-create-http-endpoint to hidden.

            // first publishing without creating a new saved template.
            'auto-save-changes' => TRUE,

is not in this MR. Is it obsolete?

Been pairing with @f.mazeikis to get this across the line!

🚢, which means ✨ Create new Templates menu Active is now unblocked!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

There is bug where suggestedPreviewEntityId is being sent back as a string not int.

Will post fix and test in new MR

Something came up while i started working on ✨ Create new Templates menu Active :

So the frontend has to display the content types and also the templates in the left menu. The below is currently rendering what is returned from /canvas/api/v0/config/content_template. But the issue is, that endpoint only provides bundles that have existing content templates. But I believe we want to render all the available content types even if it doesn't have a template yet (just have an empty accordion).

/canvas/api/v0/ui/content_template/view_modes/node returns all the available bundles so we can maybe use that endpoint to display the left menu, but endpoint doesn't provide a bundle label.

I see 2 ways to solve this:

#1. If the frontend is going to use /canvas/api/v0/ui/content_template/view_modes/node to display the menu on the left, then we need the bundle label available. But the downside of this is we would need to make an extra request to the content template to get the content template specific info like suggestedPreviewEntityId and id which is cumbersome and doesn't really make sense to use the view mode endpoint to display the template menu.

#2. If the frontend uses canvas/api/v0/config/content_template/ to display the left menu, then that endpoint needs to also provide the available bundles that don't have any existing templates yet.

I prefer #2, to avoid the downside I mentioned. I don't know if there are any backend ramifications though.

#23: 🥲 That was one of the last tweaks/fixes we did, and tests were green. Thanks, LGTM!

#26:

Ah but this is slightly different! It’s not asking to list view modes that don’t have a template yet. It’s just asking to create the full hierarchy of (supported) content entity types and bundles!

That seems totally doable! 👍

@tedbow in#23 and in your !33 MR: you're making it crystal clear that I did not review CanvasConfigEntityHttpApiTest::testContentTemplate()() at all 😰 I deemed it low-risk enough to unblock @hooroomoo.

The good thing @hooroomoo was unblocked. 👍

The bad news is that you found this small bug, but then also found missing test coverage, with inaccurate comments, and in looking at it now, there's even more missing test coverage and even an unaddressed @todo 😅 Fixing that.

there's even more missing test coverage and even an unaddressed @todo

And turns out that the test coverage that did land is not trustworthy enough 😰, because it's apparently consistently relying on ContentTemplate::normalizeForClientSide() to generate test expectations. Which means the expectations and the actual values are generated by the same code, which undermines the value of the tests.

I'll tackle that while addressing #26 in a separate MR. @tedbow's MR is good to go as-is: it fixes the bug, has test coverage, and fixes any comments that are copy/paste remnants from other CanvasConfigEntityHttpApiTest::test*() methods 👍

wim leers → closed merge request !1507

Per #26:

Both MRs (expand/fix tests + build what @hooroomoo requested in #26) are on the verge of landing 👍

Result for #26, if I temporarily peek into the future and allow multiple content entity types, and not just node:

{
  "node": {
    "label": "Content types",
    "bundles": {
      "article": {
        "label": "Article",
        "viewModes": {
          "full": {
            "entityType": "node",
            "bundle": "article",
            "viewMode": "full",
            "viewModeLabel": "Full content",
            "label": "Article content items — Full content view",
            "status": false,
            "id": "node.article.full",
            "suggestedPreviewEntityId": 1
          }
        }
      },
      "page": {
        "label": "Basic page",
        "viewModes": []
      }
    }
  },
  "user": {
    "label": "Users",
    "bundles": {
      "user": {
        "label": null,
        "viewModes": []
      }
    }
  },
  "taxonomy_term": {
    "label": "Taxonomy",
    "bundles": {
      "tags": {
        "label": "Tags",
        "viewModes": []
      }
    }
  }
}

And it's done 🎉 Whew!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.