🇫🇷France @just_like_good_vibes

i am using that work in UI suite DSFR theme, see Issue 3484134 📌 [1.1.x] Adopts the new Icon API Active

thanks for all the precious feedbacks.

after a few tries, i may have figured it out.

Hello,
i just rebased your MR and resolved the merge/rebase conflict.
i will do the review soon.
thank you :)

Should i move this issue to 1.1.x branch?

@pdureau, what do we do now with this issue?
i am not sure to fully understand yet.

please advice

it is time for this issue to go back to the queue of work to do :)

Hi guys,
let's tackle this in 1.1.x branch.

the UI component should not be aware of backend stuff (i.e. ),
such a treatment, may be added before the menu and its items are sent to rendering.

question :
- do we implement such logic in the ui_suite_dsfr theme?
- do we implement this logic in a companion module (like for example UI suite dsfr FT → )

let's discuss this, for example in the weekly meetings?

As in 🐛 Default Tile title tag to 'p' when description is empty Needs review , let's discuss this for 1.1.x branch.

title is a slot. Do we move it as a string prop?
in that latter case, it can be safely put inside a p tag.

Let's discuss this for 1.1.x branch.

title is a slot. Do we move it as a string prop?
in that latter case, it can be safely put inside a p tag.

postponed because current branch 1.1.x has target DSFR 1.12,
and DSFR 1.13 is still under progress (unreleased)

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

Hi grimreaper,
yes i understand your point.
but it's better to have one for several reasons :
- one can easily manage all metadata, as seen in the composer world (description, licence, suggests or whatever)
- when in "development mode", i personally use composer path repositories to all dev projects from my drupal projet main composer.json; I manually manage for exemple ui_icons in a directory where i can switch for a git fork branch to the main git...so on. and my project is installing ui_icons from that local directory with a symbolic link (composer path repo). whitout composer.json at root for ui_icons, it makes it harder to have such nice usage

i just proposed something.

just_like_good_vibes → created an issue.

g4mbini → credited just_like_good_vibes → .

if you agree, i can continue the work in the MR and add new kernel tests.

I really like the new direction, because it will cope with current (bad) usages out in the wild and we will use a twig function instead of a custom twig function.

What i would expect in addition to this work, is a little bit of automatic testing. may i help with that maybe?

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

Hello,
thanks for reporting.
i guess you prop is identified with the wrong prop type.
would you share the prop definition please? thanks

That was quite hard to do in fact, harder than i thought because of the way and order in which the form is processed.
The bug really only occurs in prop forms, when a switch source is triggered from the select source.
the input of the old source is getting submitted through the ajax handler and it is difficult to clean the data, early at the appropriate moment, before the bug is thrown (invalid value for the select). unfortunately, it seems not really doable in the prop form, which would have been a good place. Like when we switch source for prop, we then clean the "source" settings.

so i propose for now this implementation, only in the derivableContext source.
As soon as the invalid value is detected, it is cleaned and then we had to cover the ongoing form validation process.
The value needed to be clean, but not in form state values unfortunately but rather in form state input (because they are latter processed to overwrite the form state values).

Hello, just found the time to look a little bit.
thank you very much for your detailed info.
we will create a separate issue for that.

"Referenced entities" and "Data from a field" use the same parent source class, and are storing "derivable_context" data at the same place.
When we switch from one source to another, the old data is kept and the selected derivable_context of the old source is injected into the default value of the derivable_context for the new source.

we can fix that, independently from the current issue :)
i just created 🐛 [2.0.0-beta5] Sources bad on derivable contexts should validate the default option Active , i will push a fix soon.

just_like_good_vibes → created an issue.

thanks Pierre !

just_like_good_vibes → changed the visibility of the branch 3485201-1.1.0-from-layout to hidden.

issues have been updated thanks to @spryah:

- The classes, fr-card__link and fr-tile__link are gone since DSFR 1.5 -> 🐛 [1.0.4] remove deprecated classed in card component Active 📌 [1.1.0] DSFR 1.12 : mise à jour du composant card Active
- The dialog element in the transcription pattern changed to a div in DSFR 1.10 -> 🐛 [1.0.4][1.1.0] transcription pattern update (DSFR 1.10 evolution leftover) Active
- The classes in the form fields' error messages have changed multiple times according to the history (but it looks like it was not mentioned in the changelog ?) -> 🐛 [1.0.4][1.1.0] check classes in the form fields' error messages Active

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

please don't forget what is said in comment 15842958 from ✨ Update to DSFR 1.12 Active ,

- The classes, fr-card__link and fr-tile__link are gone since DSFR 1.5

just_like_good_vibes → changed the visibility of the branch 3487423-1.0.31.1.0-remove-constraint to hidden.

just_like_good_vibes → created an issue.

in CompatibilityChecker,
please change line 165 to

if (($reference_schema["uniqueItems"] ?? FALSE) && (!isset($checked_schema["uniqueItems"]) || !$checked_schema["uniqueItems"])) {
      return FALSE;
    }

and put priority: 1 to EnumList prop type in its attributes

good question, we can discuss that tomorrow morning on the weekly. my short answer would be yes :
- one prop for the new customizable alt
- one prop for the new customizable title

- the function getAllowedValues does not live well in PropTypePluginBase and SourcePluginBase with the name getEnumOptions, let's rather put this in a trait,
and use that trait in enum prop types and appropriate sources.
- there is a typo in "mixItems" in CompatibilityChecker

otherwise i think this is quite a bold move.

the text with "token" was copy pasted from the DSFR library changelog ;)

in just added a new class for background.

the border evolution mentioned, does not imply any change on our side.

should be fine

i take this one

just_like_good_vibes → created an issue.

card component will be updated in 📌 [1.1.0] DSFR 1.12 : mise à jour du composant card Active

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

We wait for issue 📌 [1.1.x] Adopts the new Icon API Active

just_like_good_vibes → created an issue.

Hello @spryah, thank you for the message.
YEs indeed, let's handle that in a separate issue. it will help to commit the corrections in 1.0.x-dev (if ok with DSFR 1.11) and to 1.1.x (DSFR 1.12).
Let's mention them as child issues of that current issue if possible?
thanks

it was like that in "grid_row" existing component, and in the layout options. so i kept the same naming.

but clearly we can remove the prefixes

source of inspiration hahaha :) ?

i take this one

let's go

good question. i think it is simpler to have the same internal names between all the four components... we can keep the label main for the single column case :)

i will correct the labels and repush

changes are done :)

just_like_good_vibes → created an issue.

Hello @Rajab, i wanted to add the following :
- yes the attributes variable should be used inside the twig template of a component.
- but an attribute, if declared in the component definition, should not be declared as a PHP object namespace (this is an invalid definition). i When declared, as shown by Pierre, it should be a valid piece of JSON-scheme . There is a code which is converting the array (valid in the json-schema component definition) to the attributes objects along the way.

If i am not wrong, when SDC has been introduced, the idea was not to have the twig files of components directly embedded or included by other twig presenter templates. because in that low level usage, the component part is not used, only the twig part. It is currently by passing the rendering phase of SDC, which would be normally required to used the twig file.

I found numerous bugs on the actual codebase when trying to render the example page.
therefore i did a few minor adaptations directly in this MR, even if it is not the right place.
You prefer to split into several issues?

i am currently converting, i have several questions :

- do we keep the slot name "main" instead of "first" for slot name? it would help backward compatibility but this is not straightforward to have a column slot named "main" when it is just the first one. i kept the name main for now.
- we originally have a lot of html classes for the grid--layout.html.twig file. i feel like they are not required here. i kept them for now.
- There may be a misunderstanding in the container classes. When i read the doc, it seems like classes fr-container and fr-container--fluid may be exclusive. why having two props then ? i kept two props with_container and fluid_container to have some backward compatibility but updated the twig file to have {% if with_container or fluid_container %}

as discussed during the weekly, we need to think about how to do this correctly.

Pierre mentioned a core issue to have a computed property only for props of type url.
let's follow this

we wait for #3484134 📌 [1.1.x] Adopts the new Icon API Active

i would let @Pierre answer in more details the question, but i think "include" mechanisms are to blame here in twig.
It is not appropriate to correctly trigger the rendering.

just_like_good_vibes → created an issue.

Hello,
thank you for reporting this bug. i have updated a little bit your code change proposition and i will merge that.
thanks

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

Hello @rajab, thanks for submitting an issue.

did you try to put

$ref: 'ui-patterns://attributes'

instead of

type: Drupal\Core\Template\Attribute

in your sdc component definition ?

Also, this kind of error you are showing here, usually happen when using twig to manipulate what is injected into components, and especially component attributes.

Would you show us where and how you use the component which is triggering the error please?
i see in your stack trace, no trace of ui patterns.

In the meantime, you may also try to activate ui_patterns_devel module, it may catch that exception meanwhile.

thank you

just_like_good_vibes → created an issue.