LinkControl: Render edit view upon link creation

[richtabor]

To edit a link, you need to first click on the link, see a preview of the link, then click "Edit link" to get the editing state.

Instead, I propose that when creating a link, the UI goes straight into the link editing view.

The effort in #57726 will allow for the link UI to remain open upon adding a link, while this issue covers directing the user to the edit view, rather than the link preview, upon first creating a link. This way, you will immediately have the full suite of link tools and settings right off, instead of having to click around to augment the link further.

Interacting with an existing link would still render the link preview.

Part of #50891

VIsual

Once #57726 is merged, when you first create a link, you are presented with the preview state of the LinkControl popover—like this:

Instead, you should have the edit state. This way you may start manipulating the link further if you'd like to:

Note that this should only occur when you first create the link.

[getdave]

This change seems solid as well. I much prefer that we avoid a click but retain the preview of the link/entity at the top. Losing the image preview doesn't feel like a big deal to me, except from maybe if we use this control for media in which case we'll need to optimise the UI around that special use case.

[richtabor]

Losing the image preview doesn't feel like a big deal to me, except from maybe if we use this control for media in which case we'll need to optimise the UI around that special use case.

Do you mean if you've linked directly to an image file or attachment page?

[getdave]

Worthing noting that this preview step results in a11y problems so that's another good reason to remove it entirely #54063 (comment)

[alexstine]

👍 Up vote.

[jeryj]

Definitely in favor of removing the preview or combining it into the edit flow rather than a standalone popover. Full rationale here: #54063 (comment).

[getdave]

I'd like to ad some context about the term "token" that I've used on #57755.

The idea is that sometimes a link will be dynamic - i.e. it will be linking to a Post within WordPress rather than a static URL.

This typically happens when blocks such as Navigation store a reference to the Post being linked to (e.g. Post ID) within the data created by Link UI.

So for example it might store:

{
id: 1,
title: 'Sample Post'
url: '/sample-post/`
}

However if "Sample Post" changes (e.g. the slug is updated to /my-new-post/) the the Link UI still ends up linking to /sample-post/.

With the concept of a "token" we're conveying to the user the difference between linking to a Post vs a Static URL. When linking to a Post you would not be able to modify the URL of the link (we hide the field) because it's dynamic.

When linking to a static URL you can edit the URL as much as you'd like because it won't change (or a least it's not expected).

Further rationale can be understood by exploring #46891.

[getdave]

I don't think this one will land in WP 6.5 and needs punting to WP 6.6. We just need more time to refine the experience that's been introduced with the PRs that have been merged.

This has been a surprisingly complex effort.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.