Problem/Motivation
The SDC-related theme caught an issue with enabled UIP2
See #3509484: Installing UI Patterns 2.0.0 Breaks Site
Steps to reproduce
- copy https://git.drupalcode.org/project/radix/-/tree/6.0.x/components/breadcrumb in your local project
- check it with with UI Patterns Library: breadcrumb property has prop type Link (thanks to Breadcrumb prop type adapter) normally, but it may not be the case here)
- copy https://git.drupalcode.org/project/radix/-/blob/6.0.x/src/kits/radix_sta... presenter template to your local project
- check any page: the breacrumb links are empty, so Breadcrumb::transform() may not be executed
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screenshot 2025-03-10 at 21.05.49.png | 1.04 MB | smovs |
Comments
Comment #2
smovs commentedTesting env.
radixand inserted it as a component intoui_suite_bootstrap. I saved the whole structure of the radix component (just renamed it breadcrumb_radix) to compare ui_suite_bootstrap and radix variations of the breadcrumb.ui_suite_bootstrapcomponent, I added the radix version in the breadcrumb.html.twig template for comparison.Twig tweak module with debugging shows that radix version contains all necessary data and doesn't work properly with UIP2 mostly because of the naming of variables.
Radix version uses the default core twig template for the breadcrumb with"url" and "text" naming (see function
template_preprocess_breadcrumb()in core theme.inc)In
BreadcrumbSource(UIP2) as I see we rename "text" into "title" and the related ui_suite_bootstrap theme uses "url" and "title" instead of "url" and "text" naming in the breadcrumb component in twig template.It seems the Radix breadcrumb component receives already changed links props in
$variables['breadcrumb']from UIP2 in the twig template.Unfortunately, I can't clue why xdebug is not triggering in the BreadcrumbSource on my local copy.
I can't figure out which step contains changing breadcrumb array because $variables['breadcrumb'] in the template_preprocess_breadcrumb() in Core contains pairs URL + text.
Comment #3
smovs commentedUPD.
I discussed this issue with @pdureau and he suggests look at these parts of the code:
https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Componen...
https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Plugin/U...
Will setting a"title" as a required property be relevant? No side effects?
Comment #4
pdureau commentedComment #5
pdureau commentedComment #6
smovs commentedSorry for postponing the task.
What I found during debugging:
LinksPropTypeis executed whenBreadcrumbhas already executed and prepared links in both variants.During the execution of the
normalizeLink()in theLinksPropType, the UIP2 unset$item["text"], which contains an object with the link's title.After that, twig templates containing links implemented by Drupal Core twig template examples (e.g. links.html.twig, breadcrumb.html.twig) look broken.
In my point of view, we can do something like that:
If
unset($item["text"])is put inside a comment or use the code above, breadcrumbs work flawlessly for both variations.In this case, we have a kind of fallback for Core-related twig templates but with a converted string for the link's title by UIP2 way.
Comment #7
just_like_good_vibeshello there :) interesting issue and discussion. from my point of view, it would be nice to have some new tests (with the solution or without any solution if no solution is required) of this issue. Ideally, those tests would cover different "classic" situations.
Comment #8
pdureau commentedComment #9
liam morlandWhat controls
LinksPropTypebeing executed? I am having a problem in Radix that seems related to this. Whenui_patternsis installedLinksPropTypechanges the values passed fromradix:navtoradix:dropdown-menu. It convertsUrlobjects into strings, butradix:dropdown-menuneeds them to beUrlobjects. So, I want to understand what causesLinksPropTypeto be executed on these values.Comment #10
pdureau commentedThis issue could be fixed after we merge #3567610: Adopt Core's stream wrapper
Today, the schema in the PropType have 2 distinct usages:
ui-patterns://stream wrapper in JSON schema referencesCompatibilityCheckerto guess which prop has which typeThose 2 different usages can sometimes take us to conflicting situation where a schema must be complete enough to be used in JSON schema references but not too specific to be caught by
CompatibilityChecker.This the case here. So, once #3567610: Adopt Core's stream wrapper is merged, we can:
schema.jsonreference, so it can be used by component authors without enforcing too muchOr the other way around :) I am a bit tired and the topic is a bit old to be remembered correctly.
Comment #11
pdureau commentedhi Liam,
Indeed,
urlsub-property in theitemscomponent prop are not defined as string but as object in radix:dropdown-menuSo, the
itemsprop must not be processed as LinksPropType which is expecting a string for the url sub-property:It must be ignored.
Maybe there is something to do in the
Drupal\ui_patterns\SchemaManager\CompatibilityCheckerservice where I see a missing check in object properties.This is a distinct subject as the smovs' one about
radix:breadcrumb, so let's create a new issue: #3571216: CompatibilityChecker must check object propertiesComment #12
pdureau commentedWork about
radix:dropdown-menuwill be done in the other issue. We keep this one forradix:breadcrumbComment #13
liam morlandI am experiencing the problem described in #2:
textis being changed totitleso breadcrumbs do not appear. The solution described in #6 would likely fix this.One site that I am working on has the problem and one doesn't. They both have
ui_patternsinstalled. On the one that works, there doesn't appear to be any processing of thebreadcrumbsarray.Comment #14
liam morlandThe breadcrumbs are fixed by the current merge request in #3571216: CompatibilityChecker must check object properties. The block titles are not fixed; they still appear as "1".
Comment #15
pdureau commentedCool, let's close both tickets once #3571216: CompatibilityChecker must check object properties is merged.
Comment #16
just_like_good_vibesComment #18
liam morlandIn what issue was the block title problem fixed?
Comment #19
pdureau commentedHi Lian,
Can you create a ticket about this?
Comment #20
liam morlandI see that the property title fix was added in #3571216: CompatibilityChecker must check object properties.