🇫🇷France @Grimreaper

TODO

UI Styles:
- Update Stylesheet generator:
- Check if drilling is still needed:
- Check if MachineNameTrait is still needed:
- tests updated:
- provide Drush code upgrade command:
- update documentation

UI Styles Block:
- current features:
- tests updated:
- config update:

UI Styles CKE5:
- current features:
- tests updated:
- config update:
- need to pass to a system of custom attributes to able to create a filter plugin that will be able to add attributes and attach library.
- on-the-fly style generation wrapped in .ck-content may be simplified to only load the library of the enabled style plugins. No more need to load all the libraries with parent theme recursively.

UI Styles Entity Status:
- current features: OK
- tests updated:
- config update:

UI Styles Layout Builder:
- current features:
- convert hook_entity_view_alter into hook_entity_view?
- tests updated:
- config update:

UI Styles Page:
- current features: OK
- Add utilities on html and body to have equivalent of ui_skins mode.
- tests updated:
- config update:

UI Styles Library:
- current features: OK
- Rework library:
- tests updated:

UI Styles UI Patterns:
- current features:
- tests updated:
- config update:

UI Styles Views:
- current features:
- tests updated:
- config update:

UI Styles 1:
- warn extra deprecated
- mark stuff as deprecated

I will start/continue to update contrib modules to test with the new API.

Most of the stuff remaining here are to write tests.

If some review could be done to indicate if there is a blocker or an architecture problem before writing tests on stuff that will require rework it would be nice.

Thanks!

TODO:
-
-
-
-
-
-
-
- support of prefers-color-scheme or light-dark()

To test:
-
-
-
- StyleDefinition applyOrBubbleOnAttribute
- StyleDefinition applyOnAttribute
- StyleDefinition applyOrBubbleOnArray
- Plugin manager getDefinitionsForTheme.
- Form element with theme.
- Attribute object
- Attribute helper
- style application logic
- event subscriber
- bubbleablemetadata change

TODO:
- finish event subscriber for html/body
- add helper/refactor how to apply styles. Put logic into Style definition to avoid duplication between renderer and Attribute?
- drop short syntax for options.
- description of option.
- item_attributes? When adding a style, add optional parameter to specify attribute key?
- add lifecycle/deprecation properties on style and/or on style options?
- ensure big_pipe compatibility? not sure if relevant that a style alters body/html attributes asynchronously after page had been rendered.

To test:
- Plugin manager getDefinitionsForTheme.
- Form element with theme.
- target property is now an enum
- Attribute object
- Attribute helper
- no more option short syntax
- description on option
- style application logic
- event subscriber

Documented Core patch.
Documented update workflow.
Refactored code duplication between hook_update_N and Drush command.
Added message at the end of hook_post_update_NAME.

I let @nicoloye prepare automated tests.

Also try to:
- update the ui_examples examples to use this new API.
- update components template and presenter templates to use this new API.

It would require to wait for ui_suite_bootstrap 5.3.x or to increase Core requirements.

grimreaper → created an issue.

Idea of the night.

Should we add lifecycle/deprecation properties on style and/or on style options?

Discussed with @pdureau.

So, everything is OK:
- attributes.addStyle
- renderer / render array #styles
- preprocess callback (will alter directly $variables['#attached'] and $variables['#attributes'])

In each case:
- #attributes for kind: utility and kind: mode with empty target
- #attached html_head for kind: mode with target: meta
- #attached styles for kind: mode with target: html/body, then an event subscriber will put in html attributes or body attributes.
- #attached library for the library of the style plugin.

To add style utilities to html attributes or body attributes, use preprocess_html callback, (or force putting a style utility in #attached styles and default to body attributes).

$element['#attached']['styles'] = [
  'color_mode' => 'light',
];

Problem to solve is compatibility with big_pipe for #attached styles, and not sur if needed to be solved as for html and body tags big pipe should not intervene for those render element.

Also discussed about options:
- drop short syntax
- allow description per option

utility: use attribute only
If mode: look at target.

Twig attributes: new method addStyle
- add attribute:
-- empty target: OK
-- meta:
-- html/body:
- attached library: OK

render array:
- add attribute:
-- empty target: OK
-- meta: OK
-- html/body: Ok via attached.
- attached library: OK

Preprocess callback: #styles not usable.
- add attribute:
-- empty target: ?
-- meta: ?
-- html/body: ?
- attached library: ?

new attached key: styles:
- target:
-- attribute: value

$element['#attached']['styles'] = [
  'html' => [
    'class' => [
      'foo',
    ],
  ],
  'body' => [
    'data-bs-theme' => 'light',
  ],
];

OR

- target:
-- plugin_id: plugin_option

$element['#attached']['styles'] = [
  'html' => [
    'colors_background_color' => 'bg_primary',
  ],
  'body' => [
    'color_mode' => 'light',
  ],
];

With second option, possible during resolution to make usage of Attributes object so we can benefit from AttributeHelper::matchCollectionsTypes

UI Skins:
- preprocess HTML to set global theme: to replace with event subscriber executed before the one in Core handling html_attributes and body attributes, so able to set attachments.
- theme form settings alter: to put in UI Styles as now modes will be styles managed.
-- 2 styles form elements: one for html, one for body. Need to filter out styles by target (not just kind)
-- that way possible to handle ✨ Add an interface to apply ui styles to the page body? Active

UI Styles Block:
- preprocess block: need to make it work preprocess callback

UI Styles CKE5:
- need to pass to a system of custom attributes to able to create a filter plugin that will be able to add attributes and attach library.
- on-the-fly style generation wrapped in .ck-content may be simplified to only load the library of the enabled style plugins. No more need to load all the libraries with parent theme recursively.

UI Styles Entity Status:
- hook entity view: should be unaffected or worst case, fall into same as preprocess.

UI Styles Layout Builder:
- preprocess block: need to make it work preprocess callback
- entity view alter: (to convert into hook entity view?)
- event subscriber

UI Styles Page:
- preprocess region: need to make it work preprocess callback

UI Styles UI Patterns:
- handling Attribute object: so should be ok

UI Styles Views:
- hook_preprocess_views_view: need to make it work preprocess callback

grimreaper → created an issue.

Before forgetting, discussion with @pdureau, for modes, light and dark is special because tight with browser and OS features of light/dark.

We should try to handle that too. So that it can prepare to provide a live theme switcher block like on design system documentation pages.

grimreaper → created an issue.

TODO:
- Plugin manager getDefinitionsForTheme not tested yet.
- Update test target enum
- Test Attribute
- Test Attribute helper
- special bubbleable/attached for html/body?
- check target for mode only.
- put logic into Style definition to avoid duplication between renderer and Attribute + tests
- item_attributes?

I don't think we're going to get around the HTML preprocess, in fact, we won't be able to.
The core has a preprocess_html in app/core/lib/Drupal/Core/Theme/ThemePreprocess.php

Except we go through it before going through app/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php, which handles attachments.

So even introducing a new type of #attached wouldn't work.

Or, we could create an event subscriber like core/lib/Drupal/Core/EventSubscriber/ActiveLinkResponseFilter.php
which will manipulate the response's HTML and access the response's attachments.

Discussed with @pdureau.

I don't think it will be possible to add a method to attribute object because it know nothing about libraries.

So I think we will need to add a Twig function:

{% set attributes = addStyle(attributes, 'my_style', 'my_value') %}

So that it can alter the attributes object, but I am not sure that mechanism like attach_library could be triggered:

  public function attachLibrary($library) {
    assert(is_string($library), 'Argument must be a string.');

    // Use Renderer::render() on a temporary render array to get additional
    // bubbleable metadata on the render stack.
    $template_attached = ['#attached' => ['library' => [$library]]];
    $this->renderer->render($template_attached);
  }

In UI Styles, sometimes there is "#item_attributes" instead of "#attributes" for image, responsive image.

  public const array THEME_WITH_ITEM_ATTRIBUTES = [
    'image_formatter',
    'responsive_image_formatter',
  ];

Should we handle that too?

TODO:
- Plugin manager getDefinitionsForTheme not tested yet.
- Renderer to introduce #styles
- Attribute: add addStyle method.

Hi,

Dropping an idea I got, unrelated to existing thread. Just to write it out of mind.

It involves a big change.

I thought about introducing a new endpoint in Entity Share Server. This endpoint will give the list of entities and their dependencies to pull given a channel and given import config infos.

So client website tells server website "I want to import those content entities (selected through pull from or whatever) with referenced entities and this depth of referenced tree, with embedded entities in RTE, etc.".

The server website does the computation to respond the list of entities per entity type.

The client website can then do the batches on those lists. And when handling relationships, if the referenced entity exists, just reference it and that's it, it will be updated later in the batch. If the referenced entity does not exists, create a placeholder/empty entity (I guess like what Migrate does for chicken/egg problem).

It would require:
- a new endpoint on entity share server
- a new method on import processor plugins to get the query parameters to add in case it is enabled
- a new plugin type on entity share server to make the endpoint response dynamic and which will listen to the query parameters.

It would allow:
- to fix timeout/memory limit problem of the current batch problematic architecture
- allow for features like #3259377: Add an ImportProcessor plugin to fetch translations → , ✨ Handle default language and its translations at once Needs work

Fixed code review.

TODO:
-
-
-
-
- Plugin manager getDefinitionsForTheme not tested yet.
- Form element
- Renderer to introduce #styles
- Attribute: add addStyle method.

Rebased without merge commit.

Tested, and reviewed: ok

Rebasing without merge commit.

Discussed with @pdureau, splitting into modes.yml and utilities.yml, would require to create some additional YamlDiscovery classes to inject dynamilcally the "kind" also there is a risk of plugin ID collision and we want to avoid namespacing so let's have only one file.

TODO:
- Merge YAML files into styles.yml
- kind default to utility, can be manually set to kind.
- JSON schema: only allow utility and kind value for this property.
- Plugin manager provides method to get only plugins by a certain kind.
- Plugin manager getDefinitionsForTheme not tested yet.

- Form element
- Renderer to introduce #styles
- Attribute: add addStyle method.

Discussed in ✨ Add a style utility API Active .

Too side effect prone, let's stay simple.

field.html.twig wrapper ignored by UIP2 and Display Builder.

Need to take ✨ Make style definition options translatable Active into account.

For attribute object core/lib/Drupal/Core/Template/Attribute.php, add a "addStyle" method.

Discussed with @pdureau, like with Icon API and SDC.

Try to validate style definition against JSON schema.

I will use this issue to provide change for UI Styles 2 regarding Core issue ✨ Add a style utility API Active

grimreaper → made their first commit to this issue’s fork.

Do we prefix plugin IDs with provider Id like SDC ?

In this case it would require to put in place a "replaces" mechanism like SDC too?

Currently override (in sub themes) of plugin ID are used to disable style plugin as a whole or to add/remove options.

Should it be handled like SDC only allowing adding new options to props, new props/slots but not removing ones?

This impact the subject of value validation.

I would say let's not namespace to allow override. but when processing if a style plugin is disabled (we have not put this key in the proposition by the way..) or option is missing, ignore and log.

MR ok.

https://mermaid.js.org/

Seems that a live editor exist that will ouput the markdown to copy/paste: https://mermaid.live/edit#pako:eNpVjbFugzAQhl_FuqmVkghwnDoeKjWkzRKpHTIVM...

Patch for Composer usage. Ok on my project.

Patch for Composer usage for Core 10.5.

grimreaper → created an issue.

Hi,

Thanks for the issue and the MR.

Is it related or a duplicate of ✨ Consider length for compression? Active ?

Put all changes related to coding standard on separated branch.

Maybe should go into 📌 [2.0.9] Add missing strict_types=1 diretcives Active

Hum, thinking out loud.

But if this new route has nothing to do with styles plugin, why put it in ui_styles?

Should this logic be extracted into a dedicated module?

Hi,

I have created a quick and dirty workaround to avoid problem on existing websites if they want. I copied the CSS from app/libraries/dsfr/dist/core/core.css impacting icons.

I agree that a dedicated dynamic to be generated is a good solution. But as ui_suite_dsfr is a theme it can't provide controller and route.

I think, we can create a new route in UI Styles like ui_styles.stylesheet but in the extraction logic, instead of filtering regarding the styles plugin, it could take as parameters:

- prefix (like existing route)
- library (list of libraries or string if targeting just one)

And so it would just generate from the CSS of this library.

grimreaper → made their first commit to this issue’s fork.

Hello,

I confirm that with changes in other issues, this MR is no more needed.

Hi @herved,

Thanks for opening this issue, I also witnessed that and for the moment not a problem but I understand that it is not the best possible behavior.

If I remember well, the looping on LB sections was for block content entities (put in a node LB override for example) which view modes (block content) were using LB. As block content entities were rendered inside a block.html.twig template and the attributes variables there was not the same as the one prepared in hook_entity_build...

I think we should use the occasion of UI Styles 2 to rethink this behavior.

WIP

Also block content (using DB in its view display) no more render the block title (at least in LB, not tested with Block Layout).

The MR fixes the following cases:
- block content (using DB in its view display) displayed in Block Layout
- block content (using DB in its view display) displayed in Layout Builder

Case still missing: block content (using DB in its view display) displayed in Display Builder. At least Display Builder Page Layout for now, not tested with others.

Discussed with @pdureau, to fix with ✨ [2.1.0] Add a ContentBlock source for slots with a Content entity context Active as it will allow to call the rendering of the block content entity directly without trying to render it as a block.

MR rebased.

Hello,

On a layout builder override:

I tried to add a block teaser text as a formater I chose "Component per item", then select a component and in a slot, source "[Field] Formatter", then nothing selected by default.

Is it the test to do?

Ok, I will handle that next week.

Got warnings with block preview.

Maybe that's why it was disabled.

That's way better!

I think other improvements could come later, no hurry.

Hello,

The "problem" is that with UI Icons/Core icon API, everything (rendering, accessibility, HTML) depend and is different per icon pack.

It is the icon pack which handles its accessibility as intended by the icon library.

So I am not sure what extlink can do about that.

Thanks :)

Thank! assigning I will test tomorrow

Default block has a lot of preprocesses, need to inspect that.

Need to discuss proposed solution because now block have no more title while in some places it is requested.

grimreaper → created an issue.

To merge when getting feedbacks that it will be enough and DB is stable.

Will merge when getting feedbacks that it will be enough and DB is stable.

grimreaper → created an issue.

grimreaper → created an issue. See original summary → .

grimreaper → created an issue.

It helped. Thanks.

I will use this issue to fix z-index problem of the preview when there is Navigation.

Need real life examples to complete slots mapping. Could be completed later.

No service to refactor hook_update and Drush command.

To discuss.

grimreaper → created an issue.

Ok, I will test this week.

Thanks!

In display builder settings, only save enabled options. Example with exclude where no checkboxes checks but changes in the config.

See screenshot.

Provided a draft for last point.

Adding a feedback about block categories not respected.

Currently there are the following categories:
- the slot sources blocks
- Content management (from Dashboard module)
- List (Views)
- Menus
- Others

While on block layout when adding a block I see other categories:
- Chaos Tools
- Content block
- Sitemap
- System
- UI Patterns: I guess for those one it is normal as there is the Components library
- Webform
- etc.

I know that by default when a block plugin does not declare an explicit category, it fallback to the module providing the plugin. So maybe for some plugins it is that, but I have custom block plugins with explicit category not matching the providing module machine name and the category does not appear explicitly.

grimreaper → created an issue.

grimreaper → created an issue.

Need to workaround block site branding block no more called with DB.

grimreaper → created an issue.

grimreaper → created an issue.

grimreaper → created an issue.

Potential inclusion order to fix between:
- sobki_profile_bootstrap/themes/sobki_theme_bootstrap/assets/css/styles.css?t2zmvk
- sobki_profile_bootstrap/themes/sobki_theme_bootstrap/components/nav/styles/nav.css?t2zmvk

.nav-link vs .icon-link on user menu acoount.