Handle protocol-relative URLs in LinkWidget

Created on 26 June 2017, about 8 years ago
Updated 11 August 2025, 19 days ago

Problem/Motivation

Protocol-relative URLs are saved by LinkWidget as internal:. LinkWidget::getUserEnteredStringAsUri() checks for URL strings that have no scheme, which is true for protocol-relative URLs, and assumes they are internal.

Steps to reproduce:

  1. Add a Link field to any content type.
  2. Create a new instance of that content type. In the link field, add a protocol-relative URL like: '//www.google.com'.
  3. Check the database table for the Link field that you created. See that the value in the uri column is internal://www.google.com.

Initially this report stated that when viewing the node the link was formatted as being an internal relative link. But now in D11 the link isn't rendered at all.

Proposed resolution

Make LinkWidget detect and handle protocol-relative URLs.

Remaining tasks

  1. Write an MR.
  2. Review.
  3. Commit.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Active

Version

11.0 πŸ”₯

Component

link.module

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    The issue still exists in D11, though now the link isn't rendered at all. This is caused by LinkWidget assuming that any URL with no scheme is internal. There is no check for protocol-relative URLs.

  • πŸ‡ΊπŸ‡ΈUnited States dcam
  • First commit to issue fork.
  • @riyas_nr opened merge request.
  • Allowed protocol-relative URLs in Link fields and updated constraints to exempt them from validation errors.
    Added test coverage for protocol-relative URLs.
    Moving to NR.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave
  • πŸ‡ΊπŸ‡ΈUnited States dcam

    The one thing that concerned me was the "typo" cases where someone accidentally starts an internal path with a double slash. I tested these manually:

    • //
      • Before the fix an InvalidArgumentException is caught by LinkTypeConstraintValidator and the validation fails.
      • After the fix the same thing occurs. So there's no change in behavior.
    • //example
      • Before the fix the problem as described in the issue summary occurs.
      • After the fix the URL is treated as external, just like complete URLs.

    I've wondered whether there's any benefit to adding assertions for these cases, just so we know if there's any change in behavior. I don't know that there is, so I won't insist on it. But it's something to consider.

    I think this is almost ready to go. We just need that MR comment @smustgrave made to be addressed.

  • πŸ‡ΊπŸ‡ΈUnited States dcam
  • Combined conditions and moving to NR.

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    There's a duplicate feature request issue, ✨ Link field should accept protocol-relative URLs Needs work .

  • πŸ‡ΊπŸ‡ΈUnited States dcam
Production build 0.71.5 2024