Problem/Motivation

LinkWidget provides a creative logic for internal links that converts the autocomplete entity value into their equivalent URI and vice-versa along its lifecycle.

That logic is pretty neat and could be interesting to move it to a generic trait in order to be reused by other parts of core or contrib modules that might require this logic.

A good scenario to use this trait and avoid copy&paste code is in #3445993: Provide a NavigationLinkBlock Plugin and use Help as an usage example, where Navigation links might use this logic

Proposed resolution

Move the following methods to a generic trait and implement and use the trait in LinkWidget:

  • LinkWidget::validateUriElement()
  • LinkWidget::getUriAsDisplayableString()
  • LinkWidget::getUserEnteredStringAsUri()

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3450518

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

plopesc created an issue. See original summary.

plopesc opened merge request !8411

plopesc’s picture

plopesc
he/him
Primary language Spanish
commented
Status: Active » Needs review

Initial approach moving the logic to a trait in the core namespace, so it could be used by Link module and others , avoiding to add the dependency on Link module.

A good candidate to make use of this trait would be #3445993: Provide a NavigationLinkBlock Plugin and use Help as an usage example once that MR gets in.

Final trait placement and/or Name is open for discussion, but this initial MR is ready for review.

smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Move seems straight forward and non disruptive since function names are same.

I drafted a simple CR to announce the new trait here https://www.drupal.org/node/3455776

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

In an ideal world...

if ($entity_type == 'node' && $entity = \Drupal::entityTypeManager()
        ->getStorage($entity_type)
        ->load($entity_id)) {
        $displayable_string = EntityAutocomplete::getEntityLabels([$entity]);
      }

the validation would some how allow us to use injectable code - a service or something - but it doesn't so this is okay and allows this code to be shared. See how \Drupal\Core\Form\FormValidator::doValidateForm() works.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Reviewed & tested by the community » Needs work

Thinking about this another way - should we introduce another render element - or could we move this to \Drupal\Core\Render\Element\Url and have it as an optional thing?

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Looking at how we need to manipulate the value we should add a new form element that accepts a Url object as the value.

luenemann’s picture

luenemann
Primary language German
Location Südbaden, Germany
commented
Issue summary: View changes

Upgrade issue link.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.