Add support in StringFormatter for linking to the entity edit form

As a UX Manager I approve the change: it will help apply the more standard pattern outside Drupal, and give the capacity to existing sites&users to keep what they are used to.

Edit: As a small note, I discussed with @pameeela I'd change the "Link to view" / "Link to edit" to "Link to view content " / "Link to edit content" because even if it is repetitive it makes it obvious to what it is referring to and allows to remove the description, making the UI simpler.

After some discussion with @catch, I decided to add the link relationship as an additional configuration key, because trying to convert link_to_entity into a nullable string would put us into what can only be described as the 10th circle of update path hell.

But adding a new config key is straightforward, so I think this is ready for review.

I came across a similar problem but for entity references so I created a contrib module for that.
https://www.drupal.org/project/entity_link_formatter

I wonder if this change could allow for some extensibility to allow `link_rel` to be the name of a valid link template for other modules to be able to use the formatter without extending with a new class and adding a new schema.

@rodrigoaguilera, yes, a module could extend this by implementing hook_config_schema_alter() to change the options available to the validation constraint, then probably a targeted form alter to put additional options into the settings form.

Believe this will need an upgrade path for existing fields right.

@smustgrave, this was implemented as a new setting specifically to avoid the need for an upgrade path. If the setting isn't there, it pretty much should continue doing what it already does. What leads you to believe it needs an upgrade path?

Is this not a new setting key that would appear in the config export?

It is, but that why does that necessitate an upgrade path? It will appear in exports as the config is re-saved, and re-exported, over time.

Always been under the impression under the scenario

Config export
Apply the MR
Resave the form or settings making no changes
Config export if the config changes then we need an upgrade path

In my experience as a core developer, the reason to do an update path is if the code will not function properly unless the config is updated. Or if making a backwards compatibility layer is deemed too clumsy or otherwise undesirable. This is much more likely to happen when changing existing config structures, not when adding a new setting.

Neither of those is the case here. If the link_rel setting is not already known, it defaults to canonical and keeps working as expected. There is no need for a BC layer, since this is a new feature.

So unless I'm missing something, this doesn't need an upgrade path (whew!). 😅

Added some questions to the MR.

OK -- I decided to make link_rel non-nullable and default to canonical. That avoids the painful update path, in this issue at least.

Personally, I don't like the possibility of having a single radio element as in the case of there not being an edit-form link template. I don't know if that was considered when the usability review was done or if it matters.

Was it a conscious decision to continue hiding the link form elements if there is no canonical link template? There's no discussion about it. This feels like a another issue waiting to happen when someone eventually wants to link to an edit-form route for an entity type that has no canonical route.

...yes, a module could extend this by implementing hook_config_schema_alter() to change the options available to the validation constraint, then probably a targeted form alter to put additional options into the settings form.

This was the response to the question of whether other link templates could be added as options without having to override the class. If I'm not mistaken, then this isn't true anymore. It's caused by the match() statement in settingsSummary(). If someone altered the form to add another template, then the summary would throw an UnhandledMatchError on the display form. Is there a way around it?

@phenaproxima thoughts on the last question?

If I'm not mistaken, then this isn't true anymore. It's caused by the match() statement in settingsSummary(). If someone altered the form to add another template, then the summary would throw an UnhandledMatchError on the display form. Is there a way around it?

That's a good point. I think it's fine to add a default branch to the match expression to handle this gracefully, and I've implemented that in the MR.

Rebased this with main but caused numerous test failures.

Tests fixed.

In principle, huge +1 to this. I often do weirdness like making the entity ID a hidden column in the view, then re-writing the title column as a link and using Twig into [entity_type]/{{ id }}/edit or something. This would be much cleaner.

Haven't closely looked at the MR, but wanted to ask here in the issue: how does this interact with media entities and the standalone_url setting? I believe that defaults to FALSE, so media entities have both canonical and edit-form pointing to the same edit-form route. Isn't that going to be confusing AF for people in the context of this issue? 😬

Doesn't seem particularly clean for this Field API plugin to be aware of these internals and peculiarities of media entities. But makes me wonder if we need to make it easier for Media to alter this plugin when used with media entities?

To that end, echoing the concerns of @dcam in #21 and @joachim in the MR thread about what happens to this UI when there's only 1 radio option.

My OOP brain went to having something like protected function getAvailableLinkOptions(): array in the plugin. Instead of StringFormatter::settingsForm() directly trying to populate #options as it's creating the form, it should call out to the protected helper. If the count() of the return value is > 1, we present the radios and add #states. Otherwise, maybe we just mention it in the #description of the link_to_entity element or something? Or perhaps the'link_rel element is only #markup (that still only appears with #states) in this case to mention what kind of link you'll get?

To that end, echoing the concerns of @dcam in #21 and @joachim in the MR thread about what happens to this UI when there's only 1 radio option.

This should be fixed now. The intention is that the new setting is hidden if you only have one option, in which case the existing "link to entity" checkbox acts the way it currently does.

The media stuff is a good point, but not in scope for this issue I think. We should probably open a follow-up to deal with that.

Opened #3584708: New setting in StringFormatter may impact media standalone_url setting

Tested this MR and confirmed the setting works as advertised. Logged in with a role that couldn't edit and don't see the setting anymore.

Believe that was the only feedback so will mark.

Committed to main and backported to 11.x

Added and published a change record

Thanks all

Edited the change record to add a note about https://git.drupalcode.org/project/drupal/-/merge_requests/13340#note_74...

🎉🎉🎉