🇧🇪Belgium @svdhout

borisson_ → credited svdhout → .

https://www.drupal.org/project/config_patch → provides a framework for providing patch files for config (the differences between active configuration and sync configuration).

It is plugin based, creating a output plugin for recipe creation could be a good approach here.

I can follow the approach you suggest.
If i look at it purely from the design system domain i can see some rules that a design system wants to decide upon.

• Only one primary button per page
• A specific font can only be used on a red background
• ...

I'm not sure someone would want to enforce rules like that though.

My question started from looking at it from the backend interface perspective.

We build webplatforms that will mostly be used by non technical webmasters. Therefor we always strive to keep all configuration for webmasters / content editors as minimal as possible.
Using ui styles for heading styling will add a heading style dropdown on every block entity, in 3 fieldset (block styles, block title styles, and block content styles) which would be to much configuration options for our webmasters.

The design system / frontend dev can build a list of utility styles. Maybe even combined with guides on how or when to use them.

Based on that an interface designer can design the drupal backend pages to be user friendly for webmasters and content editors, and decide on what styles should be available for specific purposes.

E.g.
the heading style can be used from CKEditor, and only on block titles.
The background-color style can only be used on block content styles.
The button style should never be used through the interface, as it would always need to use a ui pattern.

I would love to have a way for a developer to control what style should be applicable for each use case.

That doesn't need to be in the yaml file for me.
Layout options however did take a similar approach for this using the Layout Options Section (Rules) → in their yaml files.
It would make sense for all of the modules in ui suite to have a similar way of defining things.

Another approach could be to be able to configure the visibility rules on the entity type itself, that would be a more sitebuilder centric approach

svdhout → created an issue.

it looks like the feature for "3195679 - Provide default options for each content type" is causing this.
Because $node_type->id() does not yet have an identifier when creating a new content type.

svdhout → created an issue.

The patch at https://www.drupal.org/project/entity_browser/issues/2851580 🐛 Re-order + remove broken with the Entity Reference (and File) widget Needs review solves this problem.

Updated the patch, and provided an interdiff

Updated the patch in #92 to no longer use jquery once so that it can be used in D1O

$(this).once('entity-browser-remove').on('mousedown', function(e) {
becomes
$(once('entity-browser-remove', $(this))).on('mousedown', function(e) {

svdhout → created an issue.

It looks like var(--jui-dialog-z-index) is not set in claro.

In Oliveiro there is no issue because they set an z-index on the ui-dialog, i can do the same in our theme.

There probably is a problem elsewhere, i'm not sure on what the ideal approach would be for where to fix this.

svdhout → created an issue.

svdhout → created an issue.

svdhout → created an issue.

svdhout → created an issue.

svdhout → created an issue.

svdhout → created an issue.

We use the style plugin to add inline styles, like this:

span.highlight|Highlight

Saving the editor configuration throws the following error

The Style plugin needs another plugin to create <span>, for it to be able to create the following attributes: <span class="highlight">. Enable a plugin that supports creating this tag. If none exists, you can configure the Source Editing plugin to support it.

Which is correct, because we do not have a plugin defining that we can use span tags.
The approach for adding the source editing plugin works, and allows me to add the styling i want.

However, i do not really like having to add the Source editing plugin for this.

I can solve the problem in a module by adding this configuration inside a .ckeditor5.yml file:

ckeditor5_span_span:
  ckeditor5:
    plugins:
      - essentials.Essentials
  drupal:
    label: Span
    library: core/ckeditor5.essentials
    admin_library: ckeditor5/internal.admin.essentials
    elements:
      - <span>

Is allowing span tags something we want to do in core, or would it be best to create a contrib module for this?

svdhout → created an issue.

This patch adds a setting that allows to optin for sending the user uid.

I did need to set _datalayer_defaults() inside datalayer_get_data_from_page() for datalayer to be propagated.

svdhout → created an issue.