🇫🇷France @pdureau

I am sorry @miiimooo but I will close this ticket because a lot happened last 9 months with Attributes management both at Core level and at UI Patterns level. There is a big chance the issue you met has been fixed or evolved to something else.

If this proper issue is met again, let's reopen it or create a new ticket.

Done in 📌 [2.0.9] Filter out noUi components Active

Some details about the duplicate..

1. Added when the JavaScript file is directly loaded.

https://cdn.jsdelivr.net/npm/htmx-ext-sse@2.2.4/dist/sse.js
https://ui-patterns-2.ddev.site/modules/contrib/htmx/js/htmx/htmx.min.js

2. Added when drupal.init.js attaches the behaviors to the DOM

https://cdn.jsdelivr.net/npm/htmx-ext-sse@2.2.4/dist/sse.js
https://ui-patterns-2.ddev.site/modules/contrib/htmx/js/htmx/htmx.min.js
https://ui-patterns-2.ddev.site/modules/contrib/htmx/js/htmx-drupalBehaviors.js
https://ui-patterns-2.ddev.site/core/misc/drupal.js
https://ui-patterns-2.ddev.site/core/misc/drupal.init.js

Work has started

Work has started

Something else to add:

We use third_party_settings because Display Builder is not the "owner" of this config entity type ("entity view display", so we will not override the "natural" config there and use a feature which is allow us to store information in our own namespace into the config

For Page Layout config entity type, it is our own, so we store everything directly in the config root

For views, we use a mechanism similar to third_party_settings but plugin-based: Display Extender

Each time, we try to act nicely and to position ourself in the expected way

Also, let's do the new screenshot with Gin instead of Claro.

I also agree we need to jump directly into Core's HTMX API stuff without passing through drupal/htmx 1.5.

We have an issue for that: 📌 Follow Core's HTMX integration Active

@jean: do we close this issue as "won't fix" ?

To also credit: @schillerm which has helped in the contribution room in Vienna.

Hi Viktor,

As you can read in the issue description, this is not a duplicate of 🐛 Convert attributes props to an Attribute object before Attribute::merge() Active but a follow-up.

I am pretty confident about this because I am partially responsible of introducing this bug in 🐛 Convert attributes props to an Attribute object before Attribute::merge() Active where we check one of the two attributes data ($element['#attributes']) without checking the other ($element['#props']['attributes']) 😳

Thanks Christian for your suggestion. It makes sense but I would prefer to keep the MR focused on the fatal error we are already observing in the wild.

Let's wait to see what Canvas is doing.

I have another issue doing the same steps:

with display builder entity view, take the article tags field, compoenet per item, a component, and boom!

I will create an issue in Display Buildeer issue queue. I don't know the status of the current one.

I am not reproducing the layout builder issue, so it looks good to me.

pdureau → created an issue.

pdureau → created an issue. See original summary → .

pdureau → created an issue.

Being unable to reproduce the issue and, to be honest, even to fully understand it , I still believe we are not addressing the root cause here but doing a workaround.

However, I guess I am OK for it anyway because:

• @lauriii assured me we are not fixing in Core something which must be fixed at Canvas level
• we are doing the check in ComponentValidator instead of ComponentMetadata so it seems we are not messing with the real component schema and we are not doing something like 📌 Remove addition of a object type in all props Needs review

That's great we are that close to 11.3 merge ;)

Needs work. Don't use FormAjaxException but ApiController::responseMessageError() because we already handle this kind of situations.

📌 Move DisplayBuildableInterface to a Provider plugin type Active is postponed and we still don't know if it will land.

However, we keep in "postponed" because it will be easier to do it after 🐛 Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay class does not correspond to an entity type. Needs work land into Drupal 11.3

i will have a look

OK, so:

1. rebasing and repushing the branch (because of conflicts with 1.0.x)
2. move to post beta1 because not as easy as a removal, it is the logic itself we need to move to display_builder_page_layout

Too big and too late for beta1.

Weird. Because I don't think I have changed the composer files

But ok, I rebase

Some information from Mateu, the original author (not a proper quote):

it was maybe added in order to accommodate how Drupal can pass a render array in place of any type of data with the intent that it will be rendered down the line. I may be a remnant of the early days CL Components (the ancestor of SDC), when there was no slots yet, only props, so we needed a way to pass renderables in props.

Today, we have slots and we don't pass renderables in props. That may be the reason why this mechanism looks ok to be removed. Anyway, we need to be careful.

Thanks @shubham_pareek_19

I will also ping the original author of this snippet to have its opinion and maybe some information about the context of this addition.

What are you recommending? We move to dedicated issue or not?

I think that's prudent, yes.

All changes to ComponentMetadata and ComponentMetdataTests has been moved to specific issue 📌 Remove addition of a object type in all props Needs review .

Remove "11.3.0 release priority" tag because it is not blocking ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed anymore and can be merged after 11.3 if we need more time.

This issue is related for ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed

• if ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed is merged first, the current issue will need to also alter Drupal\KernelTests\Components\SchemaReferenceResolverTest before merge
• if the current issue is merged first, ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed will need to alter Drupal\KernelTests\Components\SchemaReferenceResolverTest before merged

pdureau → created an issue.

"11.3.0 release priority" tag added because needed by ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed

The MR has been simplified since comment #45. Here is the content (tests excluded).

The API itself:

• JSON schema: core/assets/schemas/v1/style.schema.json
• Form element: core/lib/Drupal/Core/Render/Element/Styles.php
• A new plugin type:
  • core/lib/Drupal/Core/Theme/Style/Exception/StyleDefinitionErrorException.php
  • core/lib/Drupal/Core/Theme/Style/StyleDefinition.php
  • core/lib/Drupal/Core/Theme/Style/StyleDefinitionInterface.php
  • core/lib/Drupal/Core/Theme/Style/StylePluginManager.php
  • core/lib/Drupal/Core/Theme/Style/StylePluginManagerInterface.php
  • core/core.services.yml
• Asset libraries handling:
  • core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php
  • core/lib/Drupal/Core/Render/BubbleableMetadata.php

Mechanisms for local application:

• Via a render property: core/lib/Drupal/Core/Render/Renderer.php
• Via a new Drupal\Core\Template\Attribute::addStyle() method: core/lib/Drupal/Core/Template/Attribute.php
• With: core/lib/Drupal/Core/Template/AttributeHelper.php

Add a new #accept_attributes render property to be used in ElementInterface::getInfo() to know in which render element the #attributes object can be added/modified:

• core/lib/Drupal/Core/Render/Element/InlineTemplate.php
• core/modules/filter/src/Element/ProcessedText.php

Use the new API with core_resize library to address ✨ Refactor system/base library Needs work so we have an use case in Core and we can see the benefit of the API:

• core/modules/system/system.styles.yml
• core/lib/Drupal/Core/Form/FormPreprocess.php
• core/lib/Drupal/Core/Render/Element/Textarea.php
• core/themes/claro/templates/form/textarea.html.twig
• core/themes/starterkit_theme/templates/form/textarea.html.twig
• core/profiles/demo_umami/themes/umami/templates/classy/form/textarea.html.twig

There are now 4 usages of this API.

As a style provider:

• UI suite Bootstrap contrib theme: ✨ POC: Core styles API and UI Styles 2 Active
• System core module: core/modules/system/system.styles.yml in the current MT

As a style plugin consumer:

• UI Styles contrib module: ✨ Support styles which are not HTML classes Active
• Layout Builder Style contrib module: 📌 Try Core's Style API proposal Active

POC is advanced enough for opening a discussion ;)

pdureau → created an issue.

pdureau → created an issue.

pdureau → created an issue.

Work in progress: https://git.drupalcode.org/project/display_builder/-/merge_requests/148

Done:

1. Add a new "display_buildable" plugin type.
2. Move DisplayBuildable logic for Entity View, Entity View Overrides, and View extender, to plugins
3. Replace display_builder_provider_info by the plugin type manager

Next steps:

1. check dependency injection and don't create too much plugin instances
2. simplify DisplayBuildableInterface as much as possible
3. move as much logic in DisplayBuildablePluginBase
4. simplify the controllers, event subscribers...
5. Move configFormBuilder to this plugin type?
6. Merge similar ::getInstance() methods
7. Rename: getBuilderUrl() -> getUrl(), getDisplayUrlFromInstanceId() -> getDisplayUrl(), getInitialContext() > getContext()
8. Update documentation and graphical schemas

After upgrading 2.0.10 (and could be related, installing ui_patterns_field and ui_patterns_ui), i no longer able to reproduce this issue.

Great news. So I am closing. Thanks for the report and the update.

For information, related issue on Canvas side: 🐛 ComponentPluginManager decorator should call decorated service instead of parent Active

Let's check if removing "widget" is enough.

OK for review.

The duplicate of 📌 Vet require-dev dependency justinrainbow/json-schema as a require dependency Active has been removed.

The duplicate of ✨ Add stream wrappers to access extension files Needs work is still here.

No phpunit error anymore. A functional test error (Drupal\Tests\field_ui\FunctionalJavascript\ManageDisplay) but doesn't seem related to the current work.

@wim, we have 2 ongoing discussions on https://git.drupalcode.org/project/drupal/-/merge_requests/13457/diffs

I have dropped the commits adding dependency injection. In review again.

Notes:

• We keep the 'profile' stream wrapper. Profiles are planned to be deprecated but we're a very long way off being able to actually do it.
• A functional test also failing but it may not be related to the current task: SettingsTrayBlockFormTest, ManageDisplayTest
• I am afraid I misunderstood this advice from @alexpott: "try to use the extension list in the container if possible to have less dependencies within the stream wrapper"

Thanks for the info. Back to work ;)

Remaining tasks:

• Rebase ✅
• Fix ExtensionStreamTest:
  • ✅ olivero theme exists but its structure has changed
  • ✅ Don't use the same module for testStreamWrapperMethods && testStreamWrapperDirnameOnMissingExtensions
• try to use the extension list in the container if possible to have less dependencies within the stream wrapper >> We are using dependency injection everywhere now ✅

Notes:

• We keep the 'profile' stream wrapper. Profiles are planned to be deprecated but we're a very long way off being able to actually do it.
• Some functional tests also failing but they may not be related to the current task: LayoutBuilderTest, ManageDisplayTest

Let's create a related issue on UIP2 side and resume after that.

Will be made it easier by 📌 Move DisplayBuildableInterface to a Provider plugin type Active

Works have started: https://git.drupalcode.org/project/display_builder/-/merge_requests/148

With:

1. Add a new "display_buildable" plugin type.
2. Add a first plugin: modules/display_builder_page_layout/src/Plugin/DisplayBuildable/PageLayout.php
3. Move the DisplayBuildableInterface implementation from modules/display_builder_page_layout/src/Entity/PageLayout.php to this plugin

Tests are still green

Next steps:

1. do the same for Entity View, Entity View Overrides, and View extender
2. simplify DisplayBuildableInterface as much as possible
3. move as much logic in DisplayBuildablePluginBase
4. Replace display_builder_provider_info by the plugin type manager
5. simplify the controllers, event subscibers...

I was expected to alter the logic, but removing was enough. It looks too easy. Did I miss something?

Let's play a bit with this subject.

it seems this logic is doing nothing anymore, anyway

Page layout display need preview. We don't have source for title and content, so let replace it on the fly for preview.

We have sources for title and content and their previews works well in PreviewPanel.

Let's try to do that for beta1

Testing with SDC themes found in the wild. Some crazy stuff over there. So, let's try to extends the logic.

The three dots have been removed in alpha6

pdureau → created an issue.

Hi @anmolgoyal74, thanks for the commit. However, the MR has not been created.

Here is an explanation of each added/modified files (outside tests).

API

We are targeting 3 personas:

Themers, with a plugin type to declare tokens with YAML discovery:

• core/config/schema/core.design_token_values.schema.yml
• core/lib/Drupal/Core/Theme/DesignToken/DesignToken.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenPluginManager.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenPluginManagerInterface.php
• core/lib/Drupal/Core/Theme/DesignToken/DtcgInterface.php
• core/lib/Drupal/Core/Theme/DesignToken/Group.php

Back developers, with a plugin type to implement the DTCG logic proper:

• core/lib/Drupal/Core/Theme/DesignToken/Attribute/DesignTokenValue.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenValueInterface.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenValuePluginBase.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenValuePluginManager.php
• core/lib/Drupal/Core/Theme/DesignToken/DesignTokenValuePluginManagerInterface.php

Site builders, with an entity type to override tokens values:

• core/config/schema/core.entity.schema.yml: add core.design_token.*
• core/lib/Drupal/Core/Theme/DesignToken/Serializer/CssVarsSerializer.php
• core/lib/Drupal/Core/Theme/Entity/DesignToken.php
• core/lib/Drupal/Core/Theme/Entity/DesignTokenInterface.php

Usage

5 first DTCG types plugins:

• core/lib/Drupal/Core/Theme/Plugin/DesignTokenValue/Dimension.php
• core/lib/Drupal/Core/Theme/Plugin/DesignTokenValue/FontFamily.php
• core/lib/Drupal/Core/Theme/Plugin/DesignTokenValue/FontWeight.php
• core/lib/Drupal/Core/Theme/Plugin/DesignTokenValue/Number.php
• core/lib/Drupal/Core/Theme/Plugin/DesignTokenValue/Typography.php

Thanks a lot for the great work done last days. It is impressive.

Some feedbacks:

JSON schemas

There is something to do with the Json schemas: https://git.drupalcode.org/project/drupal/-/tree/485bc5767e0112afac52c0b...

• We didn't find an official public URL for them. The files copied here mention https://tokens.unpunny.fun/schemas/ which doesn't look like a legit source.
• The versioning of those schemas is unclear upstream
• The mechanism to check according to the schema will be completed in the Drupal 11.4 proposal (the follow-up of the current issue)
• The way Core is organizing its schema is still unclear, especially considering the naming of the SDC ones (issue to create)

So, I am proposing to remove them for now and add them back in 11.4 proposal.

Discovery

Today, we use Drupal\Core\Plugin\Discovery\YamlDiscovery to look for {provider}.tokens.yml files.

This is good enough but could be improved by:

• only {provider}.tokens.yml file at root AND any tokens/{whatever}.tokens.yml files
• any {whatever}.tokens.yml files at root

We know there is more allowed by DTCG specification: any file ending by .tokens.json, or ending with .tokens, but it is out of scope for now (let's not introduce specific discoveries here)

Usages to check the validity of this proposal:

• in Core, conversion core_resize library to address ✨ Refactor system/base library Needs work
  • Declaration of the style: system.styles.yml
  • Usage of the style: FormPreprocess & Textarea render elements
• in Contrib:
  • Example of styles declaration: Bootstrap theme ✨ POC: Core styles API and UI Styles 2 Active
  • Example of styles usages, with integration with Core's display building tools: UI Styles ✨ [2.x] POC: Core styles API Active
  • Example of styles usages, with specific integration with Layout Builder: upcoming Layout Builder → Styles MR

Keeping on my side because of the PHPunit errors: https://git.drupalcode.org/issue/drupal-3352063/-/jobs/6934948/viewer

However, they are all related to Drupal\KernelTests\Core\StreamWrapper\ExtensionStreamTest so it has to be fixed in ✨ Add stream wrappers to access extension files Needs work

Things to check:

• try to use the extension list in the container if possible to have less dependencies within the stream wrapper
• do we get rid of the 'profile' stream wrapper?

pdureau → changed the visibility of the branch 11.x to active.

Canvas project is also expected this feature :)

Will look at the comment and move the proposed schema to test module. Adding schema will be its own issue for a next Drupal release.

Can we get an issue summary update here - what's the use case for this - why do we need it etc?

We need it as we need SDC, the Icon API and ✨ Add a CSS variables API Active :

• for frontdevs: it will allow to implement designs in sharable, business agnostic, UI logic focused, Drupal theme
• for back devs: it will allow to use the design implementation easier (see what we have done with core_resize in this MR)
• for site builders: it will be usable by the new generation of display building tools like Display Builder → or Canvas →

It looks like you can put #styles on any element and they bubble up with attachments and then get replaced.

I'm not super keen on the HTML rewriting - can we do that with placeholders like we do for scripts/css in \template_preprocess_html?

So, with the visibility shared in #45, does that means Mechanism for page wide application would need some more discussion and/or work? The API is already very valuable without this mechanism, because local applcitaion is the most common use case. So we are OK to remove core/lib/Drupal/Core/EventSubscriber/HtmlStylesResponseFilter.php from the MR.

pdureau → created an issue.