Problem/Motivation

I had this issue https://www.drupal.org/project/workflow/issues/3415585.

A view containing a contrib workflow (https://www.drupal.org/project/workflow) "From state"/"To state" item worked in Drupal 10.1.x but broke in Drupal 10.2.x because of changed behaviour in views. Somehow those two elements had the option "Link label to the referenced entity" switched on, which should invoke the canonical view of them, but the elements never had a canonical view to start with. In Drupal 10.1.x this gets ignored, in Drupal 10.2.x it actually breaks the view.

Solution was to switch the option off to make it work. But more people will probably hit the problem, and it would be the nice if the option "Link label to the referenced entity" is not shown when the element in question does not have a canonical view (which should also automatically switch the option to off).

Steps to reproduce

Proposed resolution

#4. We could at least silently catch the exception in Views to avoid breaking things entirely.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

sboden created an issue. See original summary.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

I think the change to default arguments to ::toUrl may have been the issue

It broke aggregator module too

sboden’s picture

sboden commented

The problem is with a change in functionality of calling a canonical view when the "Link label to the referenced entity" is switched on. In Drupal 10.1.x when an element does not have a canonical view Drupal "skips" requesting it, while in Drupal 10.2.x you get a WSOD when the canonical view/route is called.

For this I would propose not to show the "Link label to the referenced entity" for an element that does not have a canonical view. This would avoid Drupal calling something which does not exist. Example for this are the "From state"/"To state" fields from the contrib workflow module.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

We could at least silently catch the exception in Views to avoid breaking things entirely.

Is there a core module that can be used to write a test for this?

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented

This checkbox comes from \Drupal\Core\Field\Plugin\Field\FieldFormatter\EntityReferenceLabelFormatter, Views just reuses the field formatter, so not sure if this is something Views should be handling or the FieldFormatter itself.

@larowlan is #3371753: Fall back to 'edit-form' as default $rel in EntityBase::toUrl() the change you are referring to? The formatter seems to catch the new exception thrown there so not sure.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Yeah that's the one that broke aggregator

quietone’s picture

quietone commented
Category: Feature request » Task
Issue summary: View changes
Related issues: +#3371753: Fall back to 'edit-form' as default $rel in EntityBase::toUrl()

Version: 10.2.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Category: Task » Bug report

Just run into this with search_api_saved_searches and the SavedSearchType entity. Changing to a bug report, because this broke a view that worked in 10.1 but not in 10.2.

The problem is that the entity declares the canonical and edit-form templates to be the same:

 *   links = {
 *     "canonical" = "/admin/config/search/search-api-saved-searches/type/{search_api_saved_search_type}/edit",
 *     "add-form" = "/admin/config/search/search-api-saved-searches/add-type",
 *     "edit-form" = "/admin/config/search/search-api-saved-searches/type/{search_api_saved_search_type}/edit",

then this code makes an assumption about the route name:

    if (isset($link_templates[$rel])) {
      $route_parameters = $this->urlRouteParameters($rel);
      $route_name = "entity.{$this->entityTypeId}." . str_replace(['-', 'drupal:'], ['_', ''], $rel);
      $uri = new Url($route_name, $route_parameters);
    }

However the entity.search_api_saved_search_type.canonical route does not actually exist - it shouldn't need to because the entity.search_api_saved_search_type.edit_form route does exist.

Perhaps the whole block in EntityBase::toUrl() needs reworking to ensure that the route that it selects does actually exist; if the canonical route doesn't exist it could fall back to the edit-form route instead?

Also wondering if the real underlying problem here is the entire concept of link templates; we use routes everywhere else for generating URLs, so shouldn't link templates actually be route templates?

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Related too #3427515: Route "entity.workbench_email_template.canonical" does not exist

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.