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

CommentFileSizeAuthor
#6 Screenshot 2025-03-10 at 21.05.49.png1.04 MBsmovs

Comments

smovs created an issue. See original summary.

smovs’s picture

Testing env.

  • Drupal 11.1.2, UIP2, theme ui_suite_bootstrap
  • I copied a breadcrumb from radix and inserted it as a component into ui_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.
  • Alongside with ui_suite_bootstrap component, 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.

smovs’s picture

UPD.
I discussed this issue with @pdureau and he suggests look at these parts of the code:

Because the "normal" Links prop type was triggered before. We look for adapter plugins only if no source plugin was matched:

    if ($prop_type->getPluginId() === $fallback_prop_type_id) {
      $prop_type_adapter = $this->propTypeAdapterPluginManager->guessFromSchema($prop);

https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Componen...

So maybe (maybe because the real fix may be somewhere else) the Links prop type schema is too liberal, and catch some props which are not complaints (like this breadcrumb).

schema: [
    'type' => 'array',
    'items' => [
      'type' => 'object',
      'properties' => [
        'title' => ['type' => 'string'],
        'url' => ['$ref' => 'ui-patterns://url'],
        'attributes' => ['$ref' => 'ui-patterns://attributes'],
        'link_attributes' => ['$ref' => 'ui-patterns://attributes'],
        'below' => [
          'type' => 'array',
          'items' => [
            'type' => 'object',
          ],
        ],
      ],
    ],
  ],

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?

pdureau’s picture

Title: [2.0.1] The 'prop_type_adapter' annotations is not always added to $prop['ui_patterns'] » [2.0.1] Links prop type is detected before Breadcrumb adapter
pdureau’s picture

Title: [2.0.1] Links prop type is detected before Breadcrumb adapter » [2.0.2] Links prop type is detected before Breadcrumb adapter
smovs’s picture

StatusFileSize
new1.04 MB

Sorry for postponing the task.
What I found during debugging:
LinksPropType is executed when Breadcrumb has already executed and prepared links in both variants.

During the execution of the normalizeLink() in the LinksPropType, 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 (array_key_exists("text", $item)) {
      // Examples: links.html.twig, breadcrumb.html.twig, pager.html.twig,
      // views_mini_pager.html.twig.
      $item["title"] = $item["text"];
      unset($item["text"]);
    }
    $item["title"] = static::convertToString($item["title"]);
    $item["text"] = $item["title"];

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.

just_like_good_vibes’s picture

hello 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.

pdureau’s picture

Title: [2.0.2] Links prop type is detected before Breadcrumb adapter » [2.0.x] Links prop type is detected before Breadcrumb adapter
Status: Active » Needs work
liam morland’s picture

What controls LinksPropType being executed? I am having a problem in Radix that seems related to this. When ui_patterns is installed LinksPropType changes the values passed from radix:nav to radix:dropdown-menu. It converts Url objects into strings, but radix:dropdown-menu needs them to be Url objects. So, I want to understand what causes LinksPropType to be executed on these values.

pdureau’s picture

Title: [2.0.x] Links prop type is detected before Breadcrumb adapter » Links prop type is detected before Breadcrumb adapter

This issue could be fixed after we merge #3567610: Adopt Core's stream wrapper

Today, the schema in the PropType have 2 distinct usages:

  • as syntax shortcut for component authors thanks to the ui-patterns:// stream wrapper in JSON schema references
  • used by the CompatibilityChecker to guess which prop has which type

Those 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:

  • Set a stricter JSON schema for the PropType plugin, so it will not catch breadcrumb data structure before the PropType adapter will do
  • A more liberal JSON schema for the schema.json reference, so it can be used by component authors without enforcing too much

Or the other way around :) I am a bit tired and the topic is a bit old to be remembered correctly.

pdureau’s picture

Assigned: smovs » pdureau

hi Liam,

It converts Url objects into strings, but radix:dropdown-menu needs them to be Url objects. So, I want to understand what causes LinksPropType to be executed on these values.

Indeed, url sub-property in the items component prop are not defined as string but as object in radix:dropdown-menu

url:
  type: object
  properties:
    options:
      type: object
       ...

So, the items prop must not be processed as LinksPropType which is expecting a string for the url sub-property:

url:
  type: string
  format: iri-reference

It must be ignored.

Maybe there is something to do in the Drupal\ui_patterns\SchemaManager\CompatibilityChecker service 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 properties

pdureau’s picture

Assigned: pdureau » Unassigned

Work about radix:dropdown-menu will be done in the other issue. We keep this one for radix:breadcrumb

liam morland’s picture

I am experiencing the problem described in #2: text is being changed to title so 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_patterns installed. On the one that works, there doesn't appear to be any processing of the breadcrumbs array.

liam morland’s picture

The 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".

pdureau’s picture

Status: Active » Reviewed & tested by the community

Cool, let's close both tickets once #3571216: CompatibilityChecker must check object properties is merged.

just_like_good_vibes’s picture

Status: Reviewed & tested by the community » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

liam morland’s picture

In what issue was the block title problem fixed?

pdureau’s picture

Hi Lian,

The block titles are not fixed; they still appear as "1".

Can you create a ticket about this?

liam morland’s picture