Field for internal and external links

✋ Feature Requests
1

It would be great to have a dedicated field that allows users to select an internal record or add an external URL.

Currently, to achieve this with the existing options, we are using multiple fields (see the attached screenshot). While our solution works, it feels a bit hacky because we have a boolean field (is_external_link) that isn’t actually necessary (we are using it for the conditional fields plugin). Additionally, it is not possible to make either the internal_link or external_url fields required.

Is this something you plan to implement as a dedicated field in the future? Or do you have any suggestions for a better workaround?

image
image2628×1436 237 KB

2

Hey @kevin,

This plugin by our helpful community member @ColinDorr might be just the ticket! Showcase: Better Linking - Plugin

I don’t think we can add this to our native “Link” field functionality because that would break the backward compatibility of the data type.

Right now it’s just an record ID (or an array of them), like ‘abcdefg123’, etc. If suddenly it became an external URL like ‘https://www.example.com’, that would break any existing frontends that depend on the old ID-only behavior.

So the way to get around that is to use a more verbose field type, like a JSON field, which is exactly what ColinDorr’s plugin does, e.g.:

"betterlink": {
      "linkType": {
        "label": "Record",
        "value": "record"
      },
      "record": {
        "id": "181054613",
        "title": "Maximizing User Retention: Effective UX Design",
        [...]
      },

Or for a URL, it returns:

{
    "betterlink": {
      "linkType": {
        "label": "URL",
        "value": "url"
      },
      "record": {},
      "asset": {},
      "url": {
        "title": "URL",
        "url": "https://www.example.com"
      },
      "tel": {},
      "email": {},
      "formatted": {
        "isValid": true,
        "type": "url",
        "text": "https://www.example.com",
        "ariaLabel": "https://www.example.com",
        "url": "https://www.example.com",
        "target": "_self",
        "class": null
      },
      "open_in_new_window": false,
      "isValid": true
    }
  },

That way your frontend can determine what kind of link it is and not have to guess based on the content.

1 Like
3

Hey! I was actually just about to open a new feature request for this, but I’m glad to see it’s already being discussed here!

I agree that a unified field for both internal and external links would be really nice. Ideally, this would be a built-in feature or an officially maintained plugin by the Dato team (similar to how Web Previews works).

While I love the community’s effort, the current third-party options have some hurdles that make them a bit tricky for production:

  • Better Linking: I’ve hit a PLUGIN_PARAMETERS_TOO_LARGE limitation which makes it hard to scale as the project grows (I’ve shared more details in Issue #14).

  • Buzz Link: I unfortunately couldn’t get this one to work quite right and have opened a GitHub issue there as well (Issue #1).

It would be amazing to have a “native” feel for something as core as linking (internal/external with label & target options), so we don’t have to worry about third-party maintenance for such a common feature.

Of course I realize we might be a bit of a minority asking for this, and I know the team has probably a lot on their plate :folded_hands:

4

Hey @deven,

I want to be upfront and say that this is not currently planned, as far as I know, especially since it would entail API changes and there are already plugins for it :frowning: That said, though, it will remain an open feature request and if there is sufficient need for it and a backlash against the current approach, we can reevaluate it again.

Whatever solution we take, though, must account for the inherent difference between an internal DatoCMS record link (a record ID# reference) and an external URL (a URL-like string). That it means it would likely have to be something very similar to the existing solution of JSON field + plugin anyway.

That said, however:

  1. I’d be happy to help troubleshoot the community plug-ins with you and the author, especially since Better Linking is a pretty popular one. I’ve responded to the issue there, and if you could please provide us some more info, I will try to reproduce it on my end and PR it for the author to review. I’ve also made our own devs aware that the 10 KB limit on parameters is affecting plugins like this. But if we can fix that issue, that seems to me both the quickest and least fussy way to get this working for you in the short term.

  2. We are also considering a process by which certain plugins can become more “officially supported”, one way or another. I know it’s really hard to tell what is what right now in terms of their level of support — it’s all kind of ad-hoc at the moment — but it’s something we’re aware of and hope to have a better solution for at some point (no immediate ETA yet though, sorry).

  3. Lastly, while I don’t want to entirely duplicate the substantial effort that @ColinDorr has already put into Better Linking (with its powerful features and great UI), if all you need is a very simple plugin on top of a JSON field that lets you either link to records OR put in a URL, that is something I can probably write for you in an official capacity… would that help? It would be much lighter and simpler than Better Linking, but might be enough if your use case is dead simple?

All else being equal, IMHO, helping to fix the issues with Better Linking would probably be the most helpful for the community… do you agree? But let me know if think some other approach would be best.

In the meantime, of course, we will still keep this feature request open. If anyone hasn’t voted on it yet in the upper left of the page, please remember to do so! (And, if helpful, leave a short note about your use case).

1 Like
5

@deven With the author’s permission, I’ve fixed the bug and updated the Better Linking to properly support models now. (I shrunk the parameters size so it can much more easily fit a higher # of models per field). Please try updating to 0.2.7 in your env config and let me know if that helps at all.

1 Like
6

Yes it works now! Thank you!

1 Like