Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 293538

Change record: Implement built-in support for internal URLs

$
0
0

Updated: Comment #64

Problem/Motivation

The contrib link modules Link, URL Field and CKEditor Link supports both internal and external URLs and a lot of people use the module for internal links. Right now, the storage for the core link field data and the default widget only supports external URLs.

Steps to reproduce the issue:

  1. Install Drupal 8.x
  2. Enable the field type 'Link' in /admin/modules
  3. Goto manage fields for one of the content types in /admin/structure/types
  4. Add a new field with existing field type 'Link' and save
  5. In edit tab scroll down to see the bug

Below is the attached screenshot :
before

Proposed resolution

Implement plan C, described below.

Updated: After screenshot implementing plan C (provided on #64)
after

Remaining tasks

None.

User interface changes

A new option appears in the link field instance edit page. See screenshot from comment #64.

API changes

- both internal and external URLs can be stored (and edited in the default widget) by the link field
- the field type plugin receives its own interface (LinkItemInterface), which contains an isExternal() helper method

Original report by @Dave Reid

Current summary from #1778858: Decide on built-in support for internal URLs which was filed against the URL module issue queue:

Plan A:

  • Decide we only want to support external URLs in the widget and change nothing. Leave internal URL widget for contrib.
  • Pros: Lowest complexity
  • Cons: Users may find out-of-the-box solution limiting.

Plan B:

  • Rename the current widget from 'URL field' to 'External URL field' and add a new 'Internal URL field' widget.
  • Pros: we support both, not too much extra code
  • Cons: this makes a specific instance only able to use one or the other and not mix.

Plan C:

  • Add an option on the field instance to have the administrator say if this field supports internal only, external only, or both. The default widget will change it's validation based on the options.
  • Pros: Able to mix/match. Seems better as a field instance setting, not a widget setting.
  • Cons: Most amount of complexity to add. Widget will not be able to support HTML5 'url' FAPI type if option is not 'external only' since the url field by nature only supports external fields.

Plan D:

  • Always use the FAPI 'url' type, and attempt to resolve what are 'local' URLs to un-aliased internal Drupal URLs.
  • Pros: Simplicity. We are able to handle both types with the same widget and use the new HTML5 FAPI type always.
  • Cons: Medium complexity.
  • How does this work for sites that have multiple domains (multisite or domain access) or SSL? Would we still want to add additional logic for 'Allow the following types of URLs: [X] Internal [X] External'?

Viewing all articles
Browse latest Browse all 293538

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>