🇫🇷France @pdureau

Jean, i don't undesrtand the phpstan error:

  Line   src/StateManager/StateManager.php                               
 ------ ---------------------------------------------------------------- 
  418    Offset 'summary' might not exist on array{label:                
         Drupal\Core\StringTranslation\TranslatableMarkup}|array{label:  
         string, summary: string}.                                       
 ------ --------------------------------

Is the error in the interface declaration or in the interface implementation?

It would be better to start working on this after 📌 [1.0.0-beta1] Remove Island's specific Form classes Active is merged

Filter module permissions, for information:

administer filters:
  title: 'Administer text formats and filters'
  description: 'Define how text is handled by combining filters into text formats.'
  restrict access: true

permission_callbacks:
  - Drupal\filter\FilterPermissions::permissions

pdureau → created an issue.

Hi Catch,

Here is a spontaneous, quickly written, answer to start the conversation. I guess I will have the opportunity to refine my analysis later.

I think it would be useful to try the theme/render -> SDC path for one (non-form) element so that we can hopefully flush out
For me an example which you would think would be simple but unfortunately is not, is item_list. We already have multiple issues open trying to clean that up going back to at least 2008

You are right, item_list is not a simple example but an interesting one.

item_list is a template declared by Drupal\Core\Theme\ThemeCommonElements:

'items' => [],
'title' => '',
'list_type' => 'ul',
'wrapper_attributes' => [],
'attributes' => [],
'empty' => NULL,
'context' => [],

with this template from system module:

{% if context.list_style %}
  {%- set attributes = attributes.addClass('item-list__' ~ context.list_style) %}
{% endif %}
{% if items or empty %}
  {%- if title is not empty -%}
    <h3>{{ title }}</h3>
  {%- endif -%}

  {%- if items -%}
    <{{ list_type }}{{ attributes }}>
      {%- for item in items -%}
        <li{{ item.attributes }}>{{ item.value }}</li>
      {%- endfor -%}
    </{{ list_type }}>
  {%- else -%}
    {{- empty -}}
  {%- endif -%}
{%- endif %}

Used 81 times in Drupal Core:

$ grep -r theme.*item_list web/core/ | grep -v test | grep -v html.twig | wc -l
81

1. What does the new SDC for item lists look like?
2. What is the relationship between this and the replacement for #theme => links?
3. Can the duplicate views template just use the item_list SDC or does views need its own version for some reason?
4. What happens with existing uses of item_list that switch to the SDC but which are relying on theme suggestions.

Let's try a protocol. Is it a candidate to conversion to SDC?

• Is it something we can talk with a designer and document in a design system? Kind of, but a bit generic purpose
• Is there some specific markup? No, except the 'item-list__' ~ context.list_style class. Specific attributes are added from the render array only 3 times: WorkspaceListBuilder, PluginBase, FieldStorageReuseForm. SO it is marginal.
• Is there a good reason to override it for a theme to push its own rendering? Seems silly, it is use more than a generic rendering tool and overriding its look may break stuff. That's why the only preprocesses and template overrides are targeting its template suggestions: item-list--search-results.html.twig and item-list--media-library-add-form-media-list.html.twig

So, it may not a be a good candidate for SDC. At the difference of some renderables also defined in Drupal\Core\Theme\ThemeCommonElements which will shine as SDC: progress_bar, feed_icon, status_message, pager...

So, what do we do with item_list? Maybe we can add it to other toolset of template-free render elements, alongside html_tag, link, inline_template, value, submit... Let's try to keep this list as compact as possible, but for a renderable used that much with those characteristics, it may be relevant. It will also be the possibility to add the logic from theme.inc's template_preprocess_item_list if necessary.

If we go through this for one element/theme function (including the duplicates and near duplicates and the usages) from start to finish, then it would hopefully make it easier to go through the process for all the other ones.

As said before, item_list's theme suggestion's are the target of all the preprocess and overrides:

$ grep -r _preprocess_item_list web/core/ | grep -v html.twig | grep -v test
web/core/themes/claro/claro.theme: * Implements hook_preprocess_item_list__media_library_add_form_media_list().
web/core/themes/claro/claro.theme:function claro_preprocess_item_list__media_library_add_form_media_list(array &$variables): void {
web/core/themes/olivero/olivero.theme: * Implements hook_preprocess_item_list__search_results().
web/core/themes/olivero/olivero.theme:function olivero_preprocess_item_list__search_results(&$variables): void {
web/core/themes/stable9/stable9.theme: * Implements hook_preprocess_item_list__search_results().
web/core/themes/stable9/stable9.theme:function stable9_preprocess_item_list__search_results(&$variables): void {
web/core/includes/theme.inc:function template_preprocess_item_list(&$variables): void {

So, maybe let's study the SDC conversion of item-list--search-results.html.twig instead. I will update my comment tomorrow, following your questions and the proposed protocol.

Let's try to cover the feature scope before reaching beta

Looks like a cleaning task, so a beta phase task

Hi @anruether,

You are using loading your card component via a presenter template (node--h4d-project--h4d-card.html.twig).

So, as far as I know, UI Patterns has a limited action on your content slot (TwigExtension::normalizeProps() calling SlotPropType::normalize()) because UI Patterns is focusing on displays built in config and processed through the Render API.

So, I don't know why something is different after you enable ui_patterns.

It may not be related, but I see some "risky" stuff in the snippets you shared. For example, you are feeding component props with data coming from content variable (so renderables, perfect for the slots) instead of data coming from node variable (typed data, perfect for the props):

  image: content.field_h4d_project_image,
  offers_commercial: content.h4d_offer_commercial_group_content_eva_entity_view_1,
  offers_invest: content.h4d_offer_invest_group_content_eva_entity_view_1,
  offers_person: content.h4d_offer_person_group_content_eva_entity_view_1,
  profile_housing: content.field_h4d_profile_housing,

Can you run https://www.drupal.org/project/sdc_devel → and see of you have some errors?

Looks like a beta phase task.

I did the analysis and updated the issue description. Who takes the task?

when loading a fixture like bootstrap demo it has warning when rendering for each element:
Warning: Uninitialized string offset 0 in Drupal\Core\Render\Element::property() (line 29 of /var/www/html/web/core/lib/Drupal/Core/Render/Element.php)

From a fresh install, on commit d6a3f04d46a21c15e66a8b62fe25b8a9e3c98ebe (HEAD -> 3529103-1.0.0-beta1-remove-islands, display_builder-3529103/3529103-1.0.0-beta1-remove-islands):

1. I install & set default ui_suite_bootstrap from /admin/appearance
2. I go to /admin/structure/display-builder/instance/add
3. I create a demo from [display_builder_devel] Ui suite bootstrap demo
4. I also have Warning: Uninitialized string offset 0 in Drupal\Core\Render\Element::property() (line 26 of core/lib/Drupal/Core/Render/Element.php).

Is way more complicated, may be we could move it in another issue like discussed during meeting ?

OK, I will create a dedicated issue for the beta phase, so no rush.

So:

• Updated data message: Can we remove the extra "source" word. Example: "Alert source has been updated" > "Alert has been updated"
• Updated data message (when triggered by ThirdParty): Can we remove the extra "island" word and use the island's label instead of plugin ID? Example: "Icon: heroicons:arrow-down-on-square-stack has been updated by Styles"
• Attached data message: OK
• Removed data message: OK
• Add username in state history logs: OK
• Remove first col: OK

Thanks Goz. It is way more friendly like that!

I give it back to you for my 2 little feedback and the ones from Jean in the MR

pdureau → created an issue.

pdureau → created an issue.

pdureau → created an issue.

Also, let's replace

  context_requirements: ['is_display_builder_page_layout'],

by a proper, display builder agnostic, page context which could be implemented and managed in UI Patterns 2's side.

pdureau → created an issue.

Would it be possible to do the same for [Entity] ➜ Referenced [Entity]"?

So, with both modifications:

I will also have a look

Hi @4aficiona2

That's great to see another design system lover here 👍

This is in my opinion an absolute must and basis to have a Design Token API if we want to call Drupal a "Design System first" CMS. Design Tokens fuel everything and are the most "atomic" design decisions — especially if they are also system/language/type agnostic.

I agree (buildtime) Design Tokens have a central part in design system methodology. I called them "niche" in the issue description because the goal here is to make Drupal able to use an already built design system implementation.

"Working with a design system" as a different meaning according to the persona and the step:

1. As a designer, I am designing the system, and I set variables in my design tools to organize my work. Some of those variables can be shared as design tokens.
2. As a front-developer, I am implementing the design system, and I set variables in my CSS preprocessor (so, as Saas variables, Less Variables, Tailwind's @apply directives...). Those variables could also be considered as design tokens, retrieved from the ones shared by the designer. They are resolved at build.
3. As a back-developer or site builder, I am using the design system, managing my Drupal displays using what was built by the front-developers from the (buildtime) design tokens:
   • UI components
   • Icon packs
   • style utilities (in Tailwind, by design, each style option is also a design token but that's not the case in other design systems I have studied)
   • CSS variables (which are an subset of the design tokens which are overridable at runtime)
   • ...

The current issue is not for implementing a design system, but for using it. So, it is focused on the back-developer and site builder personas, to let them use the stuff built by the front-dev from design tokens, shipped i na Druapl theme, rendered by the browser. So, I don't see how the design tokens, which have already "disappeared" at this step, are fitting.

Visual workflow:

Anyway, I am not closing the door here. There may be something to do at the "using a design system" step, if I follow the hopes of some brilliant Drupalers:

• @e0ipso & @penyaskito have worked on a prototype: https://www.drupal.org/project/design_tokens →
• @d34dman is also doing some researches
• and you 😉

There are quite good tools out there like https://styledictionary.com/ to also transpile/convert them to the wished format and having "CSS variables / custom properties / runtime tokens" available is absolute necessary.

This tools looks great, it can be useful for the front-devs which want to expose some of the design tokens as CSS variables. It is a design system implementation decision.

To build our Drupal displays, why not using directly the CSS variables? So, we benefit from 2 strategic decisions made by the front-dev who:

• have already picked the tokens to expose at runtime, instead of struggling with myriad of obscure tokens
• set the default values according to the scopes ("scope" mechanism are not a thing with design tokens, it must be added at build time)

The task would be to ignore them at ComponentSelector level + at ui_patterns_blocks & ui_patterns_layouts derivation level

Decided during the weekly: we don't do knowing. That's their issue, not ours.

I will also add other little renaming related to 📌 init an user documentation in mkdocs Active

I am taking it because I need this to be done for 📌 init an user documentation in mkdocs Active

You are using Display Suite. Is https://www.drupal.org/project/ui_patterns_ds → installed?

Maybe localStorage must be namespaced by Display Builder config IDs instead of instance ID.

Can you share your entity view display YAML file?

Work has started. MR is open

Have you activated ui_patterns_layouts sub-module ?

htmx allow to manipulate browser's URL history: https://htmx.org/attributes/hx-history/

but we are not using the feature right now.

pdureau → created an issue.

Is it something to do on UI Patterns side, in their ComponentPluginManager?

Comment #108 moved to its own issue 🌱 [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems Active

@smustgrave: Done 🌱 [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems Active

pdureau → created an issue.