Found the issue:
Changed Behavior in Drupal 11.x-dev:
Before (Drupal 11.2.5):
- When Layout Builder was enabled on a core entity view display, field components remained in $display->content
- $display->getComponents() returned all configured fields
- custom_elements could copy these components when auto-generating CE displaysAfter (Drupal 11.x-dev, commit 60bb1a2b7e):
- When Layout Builder is enabled, field components are immediately removed from $display->content and moved to $display->hidden
- $display->getComponents() returns an empty array (since it just returns $this->content)
- custom_elements auto-generation finds no components to copy, resulting in fields being null
This change in behavior is actually acceptable and just a slight change in UX - as long as people have saved their custom-element entity displays. I'd expect that to be the case anyway, but we can document this change in a change-notice to play save. Generally, it could be argued that having an empty list of fields is a good default IF layout builder is used.
TL/DR: I think the status quo with behavior being changed with the core upgrade is fine and we just need to make tests check for that. In th end it's a minor-version update of core and some small changes like this are expected there. There is no change when config is exported properly anyway.
-> Let's use something like https://www.drupal.org/node/3379306 →
One more though. Maybe we should do it similar to Views, and simply have a preview-area that is always there + a button to make it load? Since we need the button to make it load anyway, the fieldset wrapper seems unnecessary. Then we could add a drop-down to select the desired preview-provider also. --> for the dropdown we need not use the plugins but get the list of provider-services from our provider-resolver.
The MR successfully addresses the remaining issues.
> Each slot gets rendered via a preview again, what is not working out in this case.
Actually, it's working out. It's just missing the tag-prefix, what cause issues.
Another issue is handling slots in previews.
Current approach for the nuxt-preview is only working well with canvas, not with regular components. Each slot gets rendered via a preview again, what is not working out in this case.
After some debugging, I figured the problem is actually on the nuxt side of things.
This commit fixed it.
However, after fixing it I found another issue with the component-preview. It does not respect the nuxtjs-drupal-ce component preview, since it's simply using h() and not renderCustomElements() helper.
MR looks good. However, when testing changes I do not see the button?
The preview is refreshed when changing formatter settings, but when e.g. renaming a field in output, I don't have a way to update the preview still? So something seems not right here.
Feedback on this change was overall positive, so let's move on and merge this for easier testing.
Changes are backwards compatible, existing install will stay on legacy format. Changes come with a new settings form. New installs will have explicit format enabled by default.
frontend PR https://github.com/drunomics/nuxtjs-drupal-ce/pull/402 is ready for review. it's backward compatible
Since our custom element class uses attributes terminology, not props, the question is what we should use here.
Overall usage:
- Custom Elements spec: "attributes" (string-only) vs "properties" (any type)
- React: "props"
- Vue: "props" (component data) vs "attrs" passed (HTML attributes)
More important, the Web Components Terminology Distinction
Attributes (HTML):
- String-only values
- Set via HTML:
- Retrieved via: element.getAttribute('title')
Properties (JavaScript):
- Any JavaScript type (objects, arrays, etc.)
- Set via JavaScript: element.imageData = {src: '...', alt: '...'}
- Retrieved via: element.imageData
--> in our case, the values may be objects, like imagedata, not only strings. So I think going with props instead of attributes makes sense + it fits the JS-world well.
I've got a new version of the changes without the dependencies, working fine for me as well. Unfortunately gitlab is down atm, so cannot push it, so attaching a full patch meanwhile instead.
While looking into why this was not fixing the issue, I figured out what is the real problem: Canvas ExtJS simply missed the slot html comments... ! I was not aware there are both component and slot comment, while the component-comments worked, slot comments were missing and cause the issue. I've fixed that in 🐛 Annotations for child components within slots are lost Active now - and this makes things working with and without (!) this fix! SRY for missing that before :-/
In any case, this fix seems to be a reasonable addition though. Honestly, I must say I don't know why it works without, possibly it depends on a lucky timing.
Looking at the code, however I'm not sure the added dependency on the update functions is right. In my understanding, it would lead to the useComponentHtmlMap's useEffect to re-render and thus trigger a re-creation of the mutation observer on every change. I think simply using the observer to trigger the updates should be good enough + the improvement of the equality check makes sense!
it turns out, this fixes the issue! So it seems the missing slot-comments were really the main problem
https://www.drupal.org/project/canvas/issues/3554239 🐛 Slots that have no markup in the in intial HTML document payload are not represented in the Overlay UI Active
oh, I just figured that the canvas-start/stop comments are there but NOT the canvas-slot-start-UUID/SLOTNAME comments!
So we need to fix this first.
thx, that looks mostly great now! I've found case where I think we should throw an exception though, see MR. Could you check that?
Adding an update with the material and demo from the drupalcon session about this:
- demo repo: https://github.com/balintbrews/drupalcon-vienna-2025-canvas-js-frontend - dddev site-install + follow README in nuxt-example!
- presentation https://docs.google.com/presentation/d/e/2PACX-1vSt2s73uhvBcr_igQmqcMoWs...…]DvaKbBuki2jjJLEHJ74nc/pub?start=false&loop=false&delayms=3000
- nuxt module: https://github.com/drunomics/nuxt-component-preview
- drupal module: https://www.drupal.org/project/canvas_extjs →
- balint's blog post and demo of astro-decoupled version of canvas (without Lupus Decoupled) https://balintbrews.com/blog/drupal-canvas-decoupled/
As clarified in the mentioned ticket, we are moving on with the new entity-generic version developed by drunomics as 3.x.
While the functionality is similar, this is a completely different module and thus there is NO upgrade path. Remove old views plugins and configure the new ones instead.
ok, many weeks have passed, much more than the required 2 weeks, + we get kars-t's approval, so I'm moving on with this now.
I'm marking 2.x as unsupported and starting 3.x with the entity-generic 3.x version as proposed.
If you are interested in maintaining 2.x please reach out to me.
2.x is unuspported now. Please reach out to me if you want to take over maintaining it.
thank you, merged. 2.x is becoming unsupported now though.
Thanks! I commented https://git.drupalcode.org/project/custom_elements/-/merge_requests/139 - please take a look.
> What we're missing is a method to generate Custom Element out of $ce_display directly.
yeah, let's introduce it then, as a separte method + make the existing method call the new helper?
Debugging this a bit, the canvas-start/end markers are correctly rendered by the wrapping component, example:
<div id="nuxt-preview-humanifyheader" class="nuxt-preview-container" data-component-name="HumanifyHeader" data-component-props="{"darkVariant":true,"backgroundColor":"crust"}" data-component-slots="{"branding":"<!-- canvas-start-aaef79ba-f04f-42bc-b888-e0229d46c9b5 --><div id=\"nuxt-preview-humanifylogo\" class=\"nuxt-preview-container\" data-component-name=\"HumanifyLogo\" data-component-props=\"{&quot;linkToFrontPage&quot;:true}\" data-component-slots=\"[]\"><\/div>\n<!-- canvas-end-aaef79ba-f04f-42bc-b888-e0229d46c9b5 -->","navigation":"<!-- canvas-start-95805f3a-b32e-4d58-b08e-f506579ab18f --><div id=\"nuxt-preview-humanifynavigation\" class=\"nuxt-preview-container\" data-component-name=\"HumanifyNavigation\" data-component-props=\"[]\" data-component-slots=\"[]\"><\/div>\n<!-- canvas-end-95805f3a-b32e-4d58-b08e-f506579ab18f -->"}" data-once="nuxt-preview"><header class="dark bg-crust"><div class="min-w-sm mx-auto flex h-24 max-w-screen-xl items-center justify-between gap-x-12 px-4 sm:px-12 md:h-32 lg:gap-x-16 lg:px-16"><div class="h-12 flex-shrink-0 items-center justify-start md:h-16"><div style="display: contents;"><!-- canvas-start-aaef79ba-f04f-42bc-b888-e0229d46c9b5 --><div id="nuxt-preview-humanifylogo" class="nuxt-preview-container" data-component-name="HumanifyLogo" data-component-props="{"linkToFrontPage":true}" data-component-slots="[]" data-once="nuxt-preview"><a class="inline-flex h-12 max-h-16 items-center gap-2 md:h-16" href="/"><span class="sr-only">Home</span><svg class="mt-2 h-full w-auto shrink-0" viewBox="0 0 489.142 489.142" xmlns="http://www.w3.org/2000/svg">...</svg><span class="text-flamingo shrink-0 text-lg uppercase tracking-widest"> Humanify </span></a></div>
<!-- canvas-end-aaef79ba-f04f-42bc-b888-e0229d46c9b5 --></div></div><div class="flex h-12 flex-grow items-center justify-end md:h-16"><div style="display: contents;"><!-- canvas-start-95805f3a-b32e-4d58-b08e-f506579ab18f --><div id="nuxt-preview-humanifynavigation" class="nuxt-preview-container" data-component-name="HumanifyNavigation" data-component-props="[]" data-component-slots="[]" data-once="nuxt-preview"><div class="md:flex md:items-center md:gap-12"><nav aria-label="Global" class="hidden md:!block"><ul class="flex items-center gap-6 text-sm"><li><a href="#" class="text-text hover:text-text/75 transition-colors">Services</a></li><li><a href="#" class="text-text hover:text-text/75 transition-colors">Blog</a></li><li><a href="#" class="text-text hover:text-text/75 transition-colors">About</a></li><li><a href="#" class="text-text hover:text-text/75 transition-colors">Careers</a></li></ul></nav><div class="flex items-center gap-4"><div class="sm:flex sm:gap-4"><a class="bg-teal text-inverted-text hover:bg-teal/90 rounded-md px-5 py-2.5 text-sm font-medium shadow-sm transition-colors" href="#"> Login </a><div class="hidden sm:!flex"><a class="bg-surface-0/75 text-text hover:text-text/75 rounded-md px-5 py-2.5 text-sm font-medium transition-colors" href="#"> Register </a></div></div><div class="block md:hidden"><button class="bg-surface-2 text-text rounded-sm p-2"><svg xmlns="http://www.w3.org/2000/svg" class="size-5" fill="none" viewBox="0 0 24 24" stroke="currentColor" stroke-width="2"><path stroke-linecap="round" stroke-linejoin="round" d="M4 6h16M4 12h16M4 18h16"></path></svg></button></div></div></div></div>
<!-- canvas-end-95805f3a-b32e-4d58-b08e-f506579ab18f --></div></div></div></header></div>so that part is working correctly
Images are defined like this:
title: Image
type: object
examples:
- src: "https://images.unsplash.com/photo-1484959014842-cd1d967a39cf?ixlib=rb-1.2.1&ixid=Mnw
xMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=1770&q=80"
alt: "Woman playing the violin"
width: 1770
height: 1180
$ref: "json-schema-definitions://canvas.module/image"
This is implemented already over at
https://www.drupal.org/project/lupus_decoupled_recipe →
Please help testing and report recipe related issues over at
https://www.drupal.org/project/issues/lupus_decoupled_recipe_dev?categor... →
Let's do some more testing before closing this though.
great, that works well!
The preview is empty for me when using nuxt-previewer, so there is some issue with that. But that should a separate issue. Done then!
Merged!
Works great now! Canvas brings all the API we need, we just need to use it correctly.
Except that I think you are looking to have those JS components live in code (and git), and not in config entities. Is that right?
Yes, the idea is that you can use whatever external tooling, IDE, frameworks etc as you like, as long as it produces a valid JavaScript file/bundle. I defined a loose contract so all that is required is defining a render() function. That way, it should be possible to wrap any kind of framework easily.
So, as you point out, code components are/will be flexible, generic JS as well, code-wise, but as I understand it's one fixed bundling process / tooling that is used.
Running it some issue when testing this on an article content type with a tags field.
Manage custom element dies, with exception:
The website encountered an unexpected error. Try again later.
Drupal\Core\Entity\EntityMalformedException: The "taxonomy_term" entity cannot have a URI as it does not have an ID in Drupal\Core\Entity\EntityBase->toUrl() (line 177 of core/lib/Drupal/Core/Entity/EntityBase.php).
Drupal\custom_elements\Processor\DefaultFieldItemProcessor->addtoElement() (Line: 327)
Drupal\custom_elements\CustomElementGenerator->process() (Line: 71)
Drupal\custom_elements\Processor\DefaultFieldItemListProcessor->addtoElement() (Line: 327)
Drupal\custom_elements\CustomElementGenerator->process() (Line: 59)
Drupal\custom_elements\Plugin\CustomElementsFieldFormatter\AutoCeFieldFormatter->build() (Line: 302)
Drupal\custom_elements\CustomElementGenerator->buildEntityComponentFields() (Line: 262)
Drupal\custom_elements\CustomElementGenerator->buildEntityContent() (Line: 205)
Drupal\custom_elements\CustomElementGenerator->generateMultiple() (Line: 178)
Drupal\custom_elements\CustomElementGenerator->generate() (Line: 1232)
Drupal\custom_elements_ui\Form\EntityCustomElementsDisplayEditForm->buildPreview() (Line: 443)
Drupal\custom_elements_ui\Form\EntityCustomElementsDisplayEditForm->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
The exception is NOT catched, so it fatals out.
Seems like just cathing RunTimeException wasn't a good idea, sry for that. Should explicitely catch EntityMalFormedExceptions or there others that we need to catch also?
Testing it on a simple page content type, I don't get it to work. The Preview field-set is there, but it's empty always?
So this got moved to
https://www.drupal.org/project/canvas_extjs →
for now.
Not yet tested with beta2, but works fine with beta1. It integrates nicely with Lupus Decoupled, but needs dev-releases for now. See
here
📌
First-class experience builder support
Active
for setup steps if you want to give it a try!
Got this complete and working. Also improved docs. Ready for final tweaks!
Thank you, much better! I did another review and left a couple of remarks at the PR.
The patch has been mostly written by arthur_lorenz, and be reviewed and slightly improved by me. I added credits for arthur.
Updating setup instructions for testing. Assuming 📌 Allow selection of suiting preview providers Active is merged.
Test setup
- Install custom_elements module with latest 3.x dev version + lupus_decoupled with latest 1.x-dev
- Install drupal canvas + https://www.drupal.org/project/issues/canvas_extjs →
- Install drupal and enable both modules
- Launch a test-frontend with https://github.com/drunomics/nuxt-component-preview configured. Use alpha9 or later.
The easiest way to do that is to clone https://github.com/drunomics/nuxt-component-preview and to use its dev-playground via `npm run dev`. However, you need to make sure CORS is configured correctly. For that, copy the example CORS config from the README into nuxt.config.ts - with your drupal base URL - Go to Lupus Decoupled settings screen, configure your base-url (e.g. https://localhost:3000) and select Nuxt as preview provider.
- Register components in Drupal canvas. For now this only works via drush:
ddev drush canvas:extjs-register https://yourfrontend.com/component-index.json
Component registration is done and works nicely now also - see 📌 Ease registration via component index Active .
got it implemented, it's rather straight-forward - some care must be taken for installations with custom_elements module versions <3.2 which do not have the new API. I tested the code with both versions, works fine.
For gitlab-ci runs, I had a first green run without current stable custom_elements version, besides some phpstan complaining about using unexiting APIs... I'm making it work with the version now so it can run against that.
yes, that's definitely possible. However, atm it's nothing that is supported out of the box, so you need a custom module to make it work.
We have been doing this with lupus-decoupled a lot in the past.
Extension points:
- https://git.drupalcode.org/project/lupus_decoupled/-/blob/1.x/modules/lu... - decorate the service to customize it
- https://git.drupalcode.org/project/lupus_decoupled/-/blob/1.x/modules/lu... and/or add URLs here
Then, you need to handle which content goes onto which domain. One simple, but not perfect approach is to add a common prefix in URL-aliases of your content, e.g. prefix /site1, then use api-path prefix, e.g. /ce-api/site1 in your nuxt site. Not perfect, since it obviously would only work for the aliased urls, not others.
Integration with domain module would probably make more sense and should be rather straight-forward, possible even out-of-the-box, there is an issue 📌 Support domain module Active . Happy to help getting this work if you would like to go for that.
Please re-open if you have more questions and feel free to reach out at slack!
I think this can be much simplified by being based solely on the preview-API which already landed in 3.x + existing render logic + existing sample-values of core. It seems like all we should have to add is some glue-code and UI on top?
I got i working quite nicely! :-)
Based upon the vue-team supported vue-component-meta package we are able to read most metadata. Generally, it buidls upon the typescript definitons and also supports enums that way. @example and @enum-labels are supported via js-tags. Given that, the generated file is served from nuxt and can be used to easily register files via drush!
https://github.com/drunomics/nuxt-component-preview/releases/tag/1.0.0-a... is released with the new feature.
I started working on this and pushed some WIP code, it's a first draft.
Disclosure & Note: I used AI to help creating this!
Created MR. For now it is hard-coded to canvas field. I opened the todo for making a better, general solution over at 📌 Auto-configure best settings based upon field type Active .
Ready. This requires some changes in extjs also. Creating issue.