Problem/Motivation
Once #3544339: Add support in StringFormatter for linking to the entity edit form lands and we can link the title to the edit page, it would be quite useful to have 'View' appear in the operations links. This nicely aligns with the changes to move local tasks into the top bar, since 'View' is now in the extras menu.
Proposed resolution
If available, add 'View' to the entity operations by default.

Remaining tasks
Review and commit.
User interface changes
Entities that are viewable at a canonical URL will get a "View" operation in their drop buttons, by default.
Introduced terminology
None.
API changes
There is no change to public API here, but the existing API's behavior will change in that it will return a "View" operation by default.
Data model changes
None.
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2025-09-25 at 6.12.21 pm.png | 14.88 KB | pameeela |
Issue fork drupal-3548596
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:
- 3548596-add-view-to
changes, plain diff MR !13312
- 3548596-backport
changes, plain diff MR !13347
Comments
Comment #2
pameeela commentedComment #5
phenaproximaComment #6
smustgrave commentedIs it possible to change "view" as a second option? I applied the MR and on the admin/content view the first operation is View when it use to be Edit. Think it still makes sense to be Edit as the title link already sends to view.
Comment #7
pameeela commentedI agree it should be last for now but the reason we want to add this is so we can link the title to edit instead. But that will be a new feature so certainly most existing instances would link the title to view
Comment #8
smustgrave commentedWill admit that will quite a change for people
Comment #9
ckrinaAs mentioned in #3544339: Add support in StringFormatter for linking to the entity edit form, +1 to this change on a UX Manager perspective to solve the transition to a more standard pattern with the option to keep the old strategy. That provides a good and flexible transition/change management strategy.
Comment #10
phenaproximaComment #11
phenaproximaComment #12
smustgrave commentedThanks! That was my only feedback.
Comment #14
lauriiiI've merged the MR to 11.x. We need a separate MR for 11.2.x because the MR doesn't apply cleanly on it.
Comment #16
phenaproximaBackport MR opened; since this changes behavior of an existing API, should we maybe check with the release managers that this is backport-safe?
Comment #18
lauriiiRealized 11.2.0 shipper already and it wasn’t a dev branch. I don’t think this qualifies for a backport so keeping 11.x only.
Comment #21
arno_vghJust a quick note for those who came up to this issue and do not (yet) want the new 'view' operation to be added to (all) the entities, it can be removed using
hook_entity_operation_alter().Example: