Decide on built-in support for internal URLs

Use case for most of our clients: the can add banners and the banner entity has an entity reference field so they can refer to an internal page easily, and also a link field so they can enter a path to a non-entity page (like a view). We use a custom formatter that checks if the entity reference is filled, if not the link field is used as output.

I would be happy with just an external link field, only thing I need to change is the entity reference, so it can 'reference' menu items as well.

The problem with internal URL's is that once the path changes the field isn't updated, so you'll get a 404. Same problem in case of a typo.

So A > B, I would avoid C, because then you almost have a duplicate of the link module.

I think C would have the most value for site builders. It contains A and B, so any use case that they cover is covered by C, plus more.

I don't know how deep you want to get into validation and formatting/theming here. My wish list for an all in one link formatter would be:

• Accepts internal and external links.
• Allows per field restriction of only internal, only external, or both.
• Recognized internal links, stores the non-aliased path, and outputs the aliased path when themed.
• Lets us do preprocessing and theming tomfoolery by telling us if the link is internal or external in a theme var.

I believe that we can only assume things when it comes to concluding to a "rough percentage" of the most-common use case. Basing our decisions on such assumptions in general is plain wrong. We need to support most common use cases (both internal/external URLs in our case - no pun intended) if we can afford it.

On another somewhat related issue, perhaps if the field was set as internal-only, then it would make more sense to have it as an autocomplete by default. Only added complexity I see in this when it comes to implementation is that a) we need to account for admin URLs besides content URLs and also user permissions and b) we perhaps need to (optionally) allow the auto-complete to accept non-existing (yet) URLs. Allowing this autocomplete field to accept non-existing URLs (free-tagging style) would allow it to handle external URLs as well as a bonus (...but would that be a feature or a bug?). Does that seem reasonable?

Last thing (of-topic - only mentioning because it seems that we'll have both URL and image field in D8 core) I wanted to mention is that we need to think about images with URLs (or the other way 'round: URLs with images). How do we do that best? Do we make it a URL field that accepts an optional image as some sort of attachment or the other way 'round having it be an Image field that has an optional URL? AFAIK we cannot have fields within fields. Do we do this taking advantage of what we can do with field collections (supposing this might also be in core)?

I would say that the most usual use case is to add a link field that doesn't care if the url is internal or external, but both plan A and B are a simpler approach and I don't think that is that bad to use 2 fields for that particular.

More on url input type for html5: http://www.w3.org/TR/html-markup/input.url.html

Option C clearly disables the option of using html5 unless we consider everything as an external, so I'd ++ A and in case there's time, implement B.

The way i imagine entering things, you enter full URLs anyways -- copypaste from browser URL bar. That supports HTML5 url too. Then if you've pasted something which starts with base_url offer (make a checbkox visible via JS states) to strip base_url from it and store it that way and re-assemble only on edit so that a dev-prod URL change doesn't break linkage.

If the URL is not external (there's a function already for that) we can just alias it and put the active base_url before it, ie show url($value, array('external' => TRUE)). The user will be presented (because the base_url matches) with the same "strip" checkbox which the user can just leave ticked. This is consistent to what the browser does anyways.

Revising

Posting some musings from IRC by davereid: Copying a link from subdomain.mysite.com/content/test-node into a text field on mysite.com/node/1/edit (using multisite). Do we just accept that this cannot resolve it in this case? I guess we could add support for this in something like Pathologic to process link fields, and just punt complex resolution to contrib.

I completely agree. If you edit site X paste links from site X. This is what core covers. If you paste from site Y, that's contrib.

D was what I was imagining in my head, but didn't spend the time to reason/type out. Big ++.

In the case of multilingual sites can't we check the URL language detection setting for the site and then depending on that setting strip either the subdomain or the prefix from the URL? I think that this way, with the language subdomain/prefix stripped the end page will be resolved based on the settings of each visitor. Right? I mean even though the URL might be rendered plain (without any language "hint") on the page, the user still gets redirected to their preferred/browser default/whatever set in the URL language detection section when they click on it. Don't they?

Don't want to kill the party, but with this you're seriously duplicating Link module.

I don't see a problem with URL field being a stripped down version of link module in core. The field type is a common request, and there can still be a space for link module alongside a core field, maybe by adding more in depth features or custom validation.

#501434: Move Link/URL field type into core landed for D8 core. Would it make sense to move this issue/discussion into the core queue?

(If not, let's make sure to create a new issue for core and summarize the essential discussion so far. FWIW, my primary vote goes for Plan D, with the small addition of turning the 'url' form element into an autocomplete, so when entering an internal path, it autocompletes to an external path. If that doesn't fly, then my secondary vote goes for Plan C, and I'd suggest to first try to conditionally override the user agent's default URL validation [which should be possible through the pattern attribute, and if that fails it is possible via JS].)

My vote goes for plan A, easy and straightforward and already landed.
In the most common scenario (content editor updating content in the Live website) they can still paste a complete internal URL and it will work.
In complex scenarios where you might have a DEV/PROD/LIVE or multiple languages I believe an entity reference field is what you should use.
A contrib link module is then where more complex things should happen. But I'm pretty sure than 95% of the users won't need it.

...Would it make sense to move this issue/discussion into the core queue?

I don't know if this question was for the module maintainers, but this has been brought up in #501434: Move Link/URL field type into core and I for one would love it if I could be done having to use an additional contrib module for doing this in D8. So, lets do switch to core queue and if it is decided to not do it in core, we switch back.

Now, as for the way to go from the proposed plans D + autocomplete for internal URLs sounds better to me too. If not that, then C.

No matter which of the two we choose to go with, I believe that having a per-widget setting to allow/limit internal/external/both is a must.

Guess this belongs to the link module.

Duplicate issue titles are never a good thing to have :)

Closed a duplicate: #1901958: Allow links without http://

Adding Plan D

@DamienMcKenna: just FYI: #2132229: Provide a "Duplicate of:" / "Duplicate issues:" two-way relation for issues.

There also should be a support of schemaless URLs, such as //google.com

Looking for this as well.

For enable internal links we can remove $absolute argument from function valid_url:

$absolute: Whether the URL is absolute (beginning with a scheme such as "http:").

Here is example for file url.module - line:

  if ($value !== '' && !valid_url($value, TRUE)) {

change to:

  if ($value !== '' && !valid_url($value)) {

But better way will be add option to field "Allow internal links".