🇫🇷France @pdureau

pdureau → created an issue.

It is way better like that, only 2-3 feedbacks ;)

pdureau → created an issue.

Finished, but I am not able to properly test because of this fatal error:

Call to protected method Drupal\ui_patterns\SourcePluginBase::t() from scope Drupal\ui_patterns\Plugin\UiPatterns\Source\SelectWidget in Drupal\ui_patterns\Plugin\UiPatterns\Source\SelectWidget->settingsForm()

PHP 8.3.8

Is it related to https://github.com/php/php-src/issues/14009 ?

pdureau → created an issue.

pdureau → created an issue.

Merged: https://github.com/twigphp/Twig/commit/045f5adec773f6430676fdda078b2fa39...

So, we keep this issue for this remaining task.

However, is sequence test is not enough when a list of renderables has mapping keys (non consecutive, strings) instead of sequence (integer, consecutive) keys.

For example a list of blocks from page layout or layout builder: each block is keyed by its UUID.

In other words:

• in Drupal, a unique renderable is always an associative array ("mapping"). In Twig, it is always a mapping. So it is OK.
• in Drupal, a list of renderables can be a list array ("sequence") or sometimes an associative array ("mapping"). In Twig, it must always be a sequence.
• When a list of renderables is an associative array in Drupal, the keys are meaningless, just traversable, and can be removed. So let's remove them before sending them to Twig in a prerender method.
• UI Patterns is a perfect place to do that because we know which variables expects renderables (slots/fields) and which are not (props/settings). It would not be easy at a Drupal core level. Same with ✨ Empty field values when not renderable Active

So, add a rule to SlotPropType::normalize() to transform this list of renderable to a proper Twig sequence, on the first level of each slot, no recursivity.

Be careful to not break layout builder :)

1.x implementation has its own specific issue : ✨ Make the Twig loops safer Postponed

Merged: https://github.com/twigphp/Twig/commit/045f5adec773f6430676fdda078b2fa39...

So, we keep this issue for this remaining task.

However, is sequence test is not enough when a list of renderables has mapping keys (non consecutive, strings) instead of sequence (integer, consecutive) keys.

For example a list of blocks from page layout or layout builder: each block is keyed by its UUID.

In other words:

• in Drupal, a unique renderable is always an associative array ("mapping"). In Twig, it is always a mapping. So it is OK.
• in Drupal, a list of renderables can be a list array ("sequence") or sometimes an associative array ("mapping"). In Twig, it must always be a sequence.
• When a list of renderables is an associative array in Drupal, the keys are meaningless, just traversable, and can be removed. So let's remove them before sending them to Twig in a prerender method.
• UI Patterns is a perfect place to do that because we know which variables expects renderables (slots/fields) and which are not (props/settings). It would not be easy at a Drupal core level. Same with ✨ Empty field values when not renderable Active

So, normalize this list of renderable to be a proper Twig sequence from the pattern (or component in UI Patterns 2.x) render element itself, as a prerender function, on the first level of each slots, no recursivity.

2.x implementation has its own specific issue : 📌 [2.0.0-beta1] Add sequence and mapping tests Postponed

Maybe we need to split Canonicalizer::canonicalize() into 2 public methods:

• one used for prop loading, with resolveQuirks(), the $schema["type"] = "integer" issue, and the "anyOF + const" we wnat to add. The changes to the schema are "persistent".
• one used only for the compatibility checker. The changes to the schema are "volatile".

Do this also for EnumListPropType

Is Bootstrap library installed?

https://git.drupalcode.org/project/ui_suite_bootstrap/-/blob/5.0.x/READM...

DONE

• composer.json update
• info.yml update
• merge drush commands?
• fix the need to execute some commands many times to work properly

pdureau → created an issue.

Add missing images

Declutter the layout

pdureau → created an issue.

Managed in issues about SDC/UIP2 conversions.

larowlan → credited pdureau → .

.settings.php is a great proposal. I think we need to promote this in all UI Suite themes.

Finally, we keep it.

Postponed because there is no clear solution now.

Jean: "We can override embed and include in Twig, but the props & slots are not easily available once they are transformed as variable in the Twig template."

Moved to beta1 because of all the current work on 📌 [2.0.0-alpha3] Use Drupal entities & plugins for the Library pages Active which is totally reorganizing the codebase.

Once 📌 [2.0.0-alpha3] Use Drupal entities & plugins for the Library pages Active is done, let's recheck everything expected by this ticket.

See also ✨ [2.0.0-beta1] Add a stories specific discovery Active

pdureau → created an issue.

Ongoing work in other issues.

Each preview can have a label (fallback to machine name either way)

TODO, but wr may need the plugin manage expected for ✨ [2.0.0-beta1] JSON schema examples property Needs work

Each preview can define the variant it uses (if empty, loop on each variants)

already done.

I think it would be nice to have a mechanism which allows a module or theme to add stories to an existing component without having to redeclare the component.

So, a successor to https://www.drupal.org/project/ui_patterns_extends → ? Let's create a dedicated issue

Sure. If you both agree, let's merge. I am just commenting, you are deciding here.

Also, it would be great to document this, especially by updating the (now outdated) schema: https://app.diagrams.net/#G1DdZDq3CYjnkev1aT_kpyrX7oNkk_2kNv#%7B%22pageI...

Also, it would be great to document this, especially by updating the (now outdated) schema: https://app.diagrams.net/#G1DdZDq3CYjnkev1aT_kpyrX7oNkk_2kNv#%7B%22pageI...

Hi guys,

I am not sure i understand everything in this ticket, but i want to share than I love it, especially 3 stuffs:

• the way you are presenting and organizing the work together
• the way you extend Drupal\Core\Plugin\Context\Context and Drupal\Core\Plugin\Context\ContextDefinition
• the removal of specific code in ui_patterns_field_formatters & ui_patterns_view and the addition of generic code in ui_patterns

It would be great if every public method is covered by an interface

• By implementing an already existing interface if possible (this is the "dream" target, it worth taking the time of investigating existing interfaces
• Else, by extending or adding a custom interface

For example, RequirementsContextDefinition::fromRequirements(array $requirements = [], ?string $label = NULL) : RequirementsContextDefinition is not covered by
ContextDefinitionInterface

SourcePluginBase::addRequirementsToContext(array $context, array $values): array; is not described by any interface AFAIK.

"tightly bundled to an SDC" may be the issue here.

As much as I like SDC components, they are UI / design thingies not CMS / building thingies. It is better to manipulate blocks & layout plugins, not directly SDC components, and some of them (I hope most of them) will be direct conversion from SDC components.

I have already posted this image in an other issue and warned about the coupling risk for the project:

https://www.drupal.org/project/experience_builder/issues/3454173#comment... 📌 Media Library integration Active

Not everything in a design system is a component

Let's look a bit forward. On our way to extends the design systems coverage of Drupal, we will meet other UI "artefacts" which are renderable in HTML, but which are not UI components.

2 examples:

• grid/layout systems: Very similar to components indeed, template-based too. So today they are implemented with SDC components, but it still be a different UI beast, often defined separately in upstream documentation. The model is a bit different too, instead of slots & props we have:
  • regions: looks like slots, but they can have a dynamic number of them which is not possible (and not wished) for UI components
  • container options (gutters ? fluid?)
  • regions options, would be "props of slots" ?? with different value by slot, also context sensitive, with different value by viewport
• icons: what is defined (the iconset) is not what is renderered (the icon), the main part of the definition is the discovery handler: do I zone a bitmap? do i look for SVG in a folder? do i parse a font? the the model and the renderable are different:
  • they have no slots but they may have settings (like "props")
  • a renderable will look like that: {#type: "icon", "#iconset": "foo", "#icon": "bar" } with optional settings
  • the rendering follow a dual mechanism: direct inclusion which depends of the discovery handler: unicode point, SVG markup, IMG HTML Element... or "calls", which may leverage Twig or not

We are only at the beginning of our design system journey. Do we want to introduce a specific tight coupling each time? Or do we want to manipulate known CMS objects without caring about their implemented design origin?

griffynh → credited pdureau → .

pdureau → created an issue.

Waitign for this to be ready: ✨ ckeditor5-stylesheets generator Active

Integrate the Drupal Media directly with the Experience Builder, allowing users to upload, browse, and select images from the Media Library.

When talking about Experience Builder, it seems we are not talking a lot about the blocks, layout, formatters... plugins. Are they still considered as first class object? Or are they becoming an afterthought? Do we plan to reimplement in Experience builder features already existing in Drupal (like Media Library Browser) instead of leveraging them?

Experience Builder is currently looking like 2 different "products" bundled in one:

• the initially promised easy-to-use, powerful & universal display builder, which will replace Layout Builders and others
• SDC & design system / tokens integration / management / building. Ambitious, but still a bit blurry.

I am worrying this "coupling":

• will ask extra unexpected work, so we will not meet our ambitious projects targets (calendar, scope...)
• will cut experience builder from large parts of the Drupal ecosystem by:
  • not exposing the SDC integration to the other tools
  • not leveraging the plugins provided by Druapl core & contrib
• will create technical debt (when we will want to replace or revamp one of the 2 parts) and change management risk (if one of the 2 parts of Experience Builder is not welcomed by the community, it will take down the other part with it)

Instead, let's restore the Drupal plugins we all know and love in the centre of the discussions and the architecture, as an interface between the display builder and the design system manager.

What do you think about that?

🤔 Why? This would result in broken components wherever images are used. Can you elaborate? 🙏

If {$ref: 'json-schema-definitions://experience_builder.module/image'} resolve to:

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"},
     "width": {"type": "integer"},
     "height": {"type": "integer"}
  }
}

The schema resolver will juste replace the reference to the resolved JSON schema snippet.

Then, the logic (is it an image?) will apply on the resolved JSON schema.

So, if a component author directly write (without using $ref):

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"},
     "width": {"type": "integer"},
     "height": {"type": "integer"}
  }
}

It will also works.

Or if a component author just writes:

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"}
  }
}

It will also works.

Or if a component author uses another reference resolving the same schema snippet.

{$ref: 'json-schema-definitions://whatever.module/amstragram'})

It will also work.

It is solid architecture, using JSON schema reference as expected, without introducing "weird" behaviour by deducing information from the characters in that URL.

We haven't gotten very far with making all of these concepts well-defined at the SDC JSON schema level, but we do have some, and we do have it for the aforementioned 2:

{$ref: 'json-schema-definitions://experience_builder.module/image-uri'}
{$ref: 'json-schema-definitions://experience_builder.module/image'}

Indeed, I was a bit "quick" pushing the opaque slot as the only solution. I still thing is by far the best, but a well-defined and structured object prop ("object" according to JSON, so an associative array, a Twig "mapping", not a PHP object) can also do the job, and the JSON schema reference system can help the author.

However, let's not look at the contents of the URI string ("experience_builder", "image") to guess if it is an image or not. Those URI, like every URI, → are opaque too. An other reference URI (ex: {$ref: 'json-schema-definitions://whatever.module/amstragram'}) pulling the same JSON schema structure must be processed the same way.

How would a SDC author declare that a component can accept a media image? (Backend)

It should not declare such a thing. Component author must declare a slot, that's all. A slot can accept any renderable. Sending a media image to the slot is the responsibility of the component user, on the CMS side.

How can we load the Media Library within the Experience Builder (which is a React SPA)? (Frontend)

It was started as a React SPA, but will it stay like that? Maybe, one day, we will consider this choice has more drawbacks than advantages.

Some proposals:

• Rename display_manager component to display because the CSS classname is "fr-display"
• It is OK to have hardcoded stuff (fieldset, radio, artwork...) in the template of this component
• Remove display_button component, it must be enough to use the existing btn component (with some special attributes injected)
• The content of display_button template (modal + button) must move to pattern-display--preview.html.twig

pdureau → created an issue.

should be fixed in Issue 3440278

Indeed, but the nesting only, and we already know that.

We keep the issue for the simplification:

• Remove UiPatternsOperations form element
• Remove buildPluginConfiguration() from SourcePluginManager

Looking at the markup, I don't think we need new components.

Link:

<button class="fr-btn fr-icon-theme-fill" aria-controls="fr-theme-modal" data-fr-opened="false">Paramètres d'affichage</button>

<button class="fr-footer__bottom-link fr-icon-theme-fill fr-btn--icon-left" aria-controls="fr-theme-modal" data-fr-opened="false">Paramètres d'affichage</button>

We already have https://git.drupalcode.org/project/ui_suite_dsfr/-/tree/1.0.x/templates/...

Modal:

<dialog id="fr-theme-modal" class="fr-modal" role="dialog" aria-labelledby="fr-theme-modal-title">
  ...
</dialog>

We already have https://git.drupalcode.org/project/ui_suite_dsfr/-/tree/1.0.x/templates/...

So, we need to find a way of using those components in Drupal (in header, but also footer). Maybe, we will need to do some non-breaking changes to those components.

Lets' move it to beta1

Waiting upstream news

Moved to beta1

Moved to beta 1

I have rebased the MR.

I am not very comfortable with this part:

        {% set is_button = item.url == 'route:<button>' ? true : false %}
        {% set is_plain_text = item.url == 'route:<nolink>' ? true : false %}

First, because we may not need the ternary:

        {% set is_button = (item.url == 'route:<button>') %}
        {% set is_plain_text = (item.url == 'route:<nolink>')  %}

Second, and that's the most important, I would prefer to not manipulate route information from the template.

UI Patterns Settings 2.2 & 2.3 were released last week with some improvement in the menu processing: https://www.drupal.org/project/ui_patterns_settings/releases/8.x-2.3 →
Is it helping?

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

Grimreaper → credited pdureau → .

Upstream PR ready for review: https://github.com/twigphp/Twig/pull/3859

pdureau → created an issue.

Merged

1: Acting on body tag is out of the scope of this module

Indeed.

3: The UI Skins theme feature allows to act on the body tag, but it will be global. Maybe you can give a look at how it works and adapt to your needs. Maybe this feature request should be opened on UI Skins, but in this case, I think the issue needs a proper concrete use case/example.

Ye,s we need a proper example to answer this question.

So in my opinion it will be a "Closed (works as designed)".

I agree, but we can first wait for a proper example. Marc-Antoine, can you share?