Insert external link on form submit

Let me try to describe why Linkit behaves this today.

In the beginning there was only one field. That field was used to search in, and when selected a result, the field got populated with a cryptic string (URI) like 'entity:node/1'. On submit, Linkit would explode the string into an array and use in the form submission. This was actually pretty good, and the "cryptic" string is a valid to use with Drupal\Core\Url::fromUri.

External links were just inserted as is. Nothing special here.

However, when we added URL substitution support, we made a small change to the URI. It became 'entity:cannonical/node/1'. I wasn't really pleased with the fact that we now have created our own URI that doesn't go all the way with Drupal core, and that takes us to how it works today.

I tried to hide the data that editors don't need to see, and only show them the title of the link target.
To hide the data was no big deal, but then I faced problems. What should Linkit set the "href" attribute to? We can't leave it blank, and to insert the title, or uuid in it doesn't make any sense. I ended up setting it to "#". Now I don't think that was a good solution either.
How to populate the fields? How to know when to populate them? What if an editor is just typing the title and then saves without selecting a result? etc....

I'm still not pleased about the solution as it is, like you said, quite hard for users to understand how it works just by using it, but I can't see a solution that fits everyone here.

The goals for a solution is:

• Be able to know the entity type, entity uuid, and which substitution plugin the filter should use when parsing the link later on.
• Clearly show the user what the link links to, both when adding a link, internal and external, and when editing it later.

Thanks for the explanation. Fixing this sounds like quite the undertaking :/

I've also noticed that it is impossible to insert a URL that is similar to site content. In my case, manually linking to # is not possible as there are nodes that contain the hash character in their title.
Also, how does LinkIt currently handle route shortcuts like <front>, <none> or <nolink>?

Regarding the solution goals...

Be able to know the entity type, entity uuid, and which substitution plugin the filter should use when parsing the link later on.

This sounds suspiciously like what the entity_embed module does. Maybe we can draw inspiration from there, or even integrate with embed ourselves?

Clearly show the user what the link links to, both when adding a link, internal and external, and when editing it later.

To me personally (as a friend of progressive enhancement), the link input field should provide the actual href attribute by default, and only use any substitutions when an autocomplete entry is selected. This way, copy-past-save workflows would be unaffected, but autocompletion would still be awesome.
One could even think of extending LinkIt's behavior to allow substitutions to detect url patterns (e.g. typing /node/4 would be detected and on edit be displayed as the pretty title).

Also, how does LinkIt currently handle route shortcuts like <front>, <none> or <nolink>

Linkit is handling <front> as we speak. To be honest, I didn't know the other ones existed. Where can I read more about those?

This sounds suspiciously like what the entity_embed module

True, we have taken inspiration from that module.

The tricky part is to allow both these internal links, with all the attributes, and the external, that doesn't have any at all in the same form.

the link input field should provide the actual href attribute by default

We could do this, but it wouldn't be 100% correct all the time. We tried this in Linkit 7, and multilingual was/is quite a pain on that version.
As it works now, we constructs the URI at "run time" with the Linkit filter. That ensures (as far as I know) that the link handles multilingual sites setups correct.

To be honest, I didn't know the other ones existed. Where can I read more about those?

I've found <none> to not be that helpful, in most cases as it simply outputs a "#" (change record). For <nolink>, which outputs text instead of a link, this was added in #2693725: Add <nolink> to allow for non-link links but a change record has not been added. The system.routing.yml additionally has the <current> route, but to be honest, neither of these seem to be really important in a WYSIWYG context. So don't stress about them :)

The tricky part is to allow both these internal links, with all the attributes, and the external, that doesn't have any at all in the same form.

Does LinkIt have to handle absolute or external links? I would think this part could be left for the core behavior to handle. That might just be naive on my part, as I haven't really looked at the code (yet).

As it works now, we constructs the URI at "run time" with the Linkit filter. That ensures (as far as I know) that the link handles multilingual sites setups correct.

I didn't mean to completely replace the href attribute when using the WYSIWYG button and trying then having to figure out what to do with the input. Instead, use the input field as-is, and only provide autocompletion. When the user accepts a suggestion, add the new attributes and override/disable/hide/whatever the original input field. That way, the default behavior would still work and LinkIt still provides its magic :)
This would be in line with the core url input fields (e.g. when editing menu links): Provide suggestions, but still accept the original input if the user doesn't like them.

In D7 we used to use the pathologic module to convert paths (/node/123) into pathaliases (/article/how-to-be-awesome) on display (via an input filter, same as LinkIt does right now). That way, the text in the editor (and also stored in the database) uses the easy to parse canonical url, but when displayed the pretty alias is used.

If someone creates a feature request for <none> and/or the others with a clear use case, I will implement them but for now I will leave them unsupported.

I still think we should provide a filter bundled with Linkit. Wim Leers has some really good points about why in #2692831: Linkit 8.x-4.x flaws from the POV of the Text Editor/CKEditor APIs in Drupal 8 core.

But if there is an easy way to get the entity path (like /node/123) I don't see why we shouldn't set that as the href instead of #.

I will have to evaluate this more before making any decisions.

Implementation ideas, patches and gui images are welcome =)

But if there is an easy way to get the entity path (like /node/123) I don't see why we shouldn't set that as the href instead of #.

That one is easy ;) That can be solved with $entity->toUrl(), available for every entity (even works on config entities).

Implementation ideas, patches and gui images are welcome =)

I don't currently have a lot of time on my hands :( If I stumble upon anything useful, I'll let you know!

This patch chages how the field is used.

- No need to click when inserting external link.
- The value populated when clicking on a autocomplete suggestion is the entity url.
- The entity url will be set to the href field. (It will still be recalculated in runtime by the Linkit filter is applicable)
- When focusing the linkit field, a search will be made. This is handy in edit scenario.