Single interface for choosing links to anything

[davecranwell]

It would be nice if a unified link widget could be created so that when creating content that links elsewhere, three fields weren't required to allow the user to choose the link destination.

Take for example a model representing a "teaser": a title, an image and a link.

The user wants to sometimes link to internal pages, sometimes external ones, and sometimes internal documents. The only way of achieving this presently is by having two "chooser" fields (Page chooser and Document chooser) and one text field, then writing opaque template logic to favour one field over another. (Or using a regular UrlField and having the user manually find the URL they want and typing it in, but that's not a real solution)

Having three fields in the model isn't a big deal, if that were unavoidable, but the experience of those three fields as an editor needs addressing.

[sixpearls]

I don't mind the way the internal Page / external link is split up, but I also think it makes sense to include internal documents in the same interface, and streamline that joint interface if possible. A couple of related nice to haves:

1. Allow the "embed" chooser to point to internal (or external?) documents. I'm not sure if that's a bad UI, but I know people who like to embed PDFs.
2. Hooks to add types of objects to the link and/or embed chooser (for example, to add a new provider without modifying the codebase). Ideally, the when the page / external link / internal document gets re-written, they will get added using the same interface that a 3rd party would use.

[davecranwell]

We've had some pretty specific user feedback that having internal and external links split up is confusing, partly because users don't know what "internal" and "external" refer to: Internal to the organisation/company i.e "back office"? External as in provided by a third party/contractor?

They wanted to "link up such and such" but were provided three fields. Reducing it to two isn't really any better as users don't see any difference between what we deem internal and external links.

[sixpearls]

Sorry, to clarify, I am all for combining the internal links and external links (and document links) into just "links." I was just saying it would better if the new, streamlined, link form was customizable, so the developer could add links to other models as desired.

Separately, I was asking for an enhancement to the "embed" tool, but that should be its own ticket.

[davecranwell]

In accordance with the "For team discussion" label, this was discussed yesterday. The upshot, if i recall correctly, is that we broadly agree that the need exists, but aren't sure how to approach it yet.

IIRC there were basically three levels of possible solution, most basic first:

1. Simple FE solution: we add some custom javascript that somehow detects groups of linky model fields used in combination, and prevents the user filling in more than one at a time. This doesn't make the UI nicer, but makes confusion less likely through simple feedback to the user.
2. Advanced FE/BE solution: We come up with a brand new widget which launches a modal, from which the user chooses which kind of link to create (similar to the link modal launched from the Rich Text Editor). The chosen link is stored in a single field which is validated e.g to check for the situation where users have manually type an absolute link to a URL actually controlled by wagtail. (and a bunch of other stuff)
3. Epic ground-up refactor: As part of the Sir Trevor re-think, we come up with the concept of fields within fields, which can be added/removed as necessary and which can toggle each other etc. E.g the Wagtailforms form panel includes fields that are only relevant when other field values are X (choices, default). This is a situation similar in many ways to the link issue.

We're approaching the end of a phase of development, which should give us breathing space to consider the ramifications of Sir Trevor more generally and how it might affect this issue more specifically. We'll be meeting to have a big brainstorm.

[mattots]

Can I add my +1 to this please. At least as things stand at the moment it would make sense to have a consistent link-adding interface between the richtext editor and other link type fields. I don't have a particular view on how this is implemented behind the scenes, but from an end-user perspective, consistency and ease of use are paramount.

[mx-moth]

I also +1 a unified internal/external link field. While a Sir Trevor integration would be excellent for embedding links in text, there are multiple use cases of having a standalone link field that is not part of a rich text environment - think of a 'link' page type that just redirects users to a different URL when visited, or a 'more information' link external to the text body, or ads in the sidebar that send the user to a URL when clicked.

[bbusenius]

+1 we would love to see this at UChicago.

[harrislapiroff]

+1

Little Weaver was just discussing this, so I checked to see if there was already a ticket for it. :)

[sonnybaker]

+1, would love to see this!

[bruecksen]

+1

[DanielSwain]

+1 Sure would like to see this feature implemented.

[harrislapiroff]

Architecturally, I wonder if this could be a MultiFieldPanel subclass that displays a tabbed interface and only allows one child to be filled in at a time... 🤔

[widma1]

+1

[Ramblurr]

We're some years on now from this original issue posting, have things changed at all?

The Richtext editor has a link/page selection screen which works great. Is it possible to use this as a standalone chooser?

I want to add a ButtonBlock and a CTABlock that enables the author to choose a page or enter their own link.

Is this possible now?

[thibaudcolas]

For people interested in this, the easiest way to do this is with a StreamField StructBlock that contains document/page/URL link blocks, like wagtail-jetstream does:

https://github.com/caltechads/wagtail-jetstream/blob/ebc2a36c6b76f25517e0c954b0c32ebe33732839/jetstream/blocks.py#L118-L151

Then jetstream has a link_url template tag which automagically outputs the correct URL based on which block was chosen in the CMS: https://github.com/caltechads/wagtail-jetstream/blob/ebc2a36c6b76f25517e0c954b0c32ebe33732839/jetstream/templatetags/jetstream_tags.py#L212-L225

---

I think it might be useful for Wagtail to have some version of this (or something better, like the UI improvements suggested above) built in, so I’ve tagged this as Needs Design Decision so we have a core team discussion at some stage.

[jkevingutierrez]

It would be great to have the Link Modal used in the RichTextBlock in the URLBlock. That way, we could add external URLs and/or internal pages using a single block.

[thibaudcolas]

FYI for people still interested in this, we’re considering bringing this in as part of the Page editor 2022 project, as part of general chooser improvements. Follow this discussion thread for upcoming updates / requests for feedback about choosers.

In the case of this feature in particular, we’ll be combining link and document choosers at least in rich text. We haven’t decided or even discussed whether we would also provide a unified panel / widget / field at the page level.

[Chadys]

+1 would love a standalone link widget and link stream block using the same interface as the link modal for richtext field. I think it can probably be done by tweaking AdminPageChooser: overriding get_chooser_modal_url to add the get parameters ["allow_external_link=true", "allow_email_link=true", "allow_phone_link=true","allow_anchor_link=true"], you get the same UI as the richtext link plugin. But then I didn't go much further than that since I'm not familiar enough with wagtail internals. The goal would be for that widget to validate and return a link string.