Linkit filter does not replace internal node reference with alias

Created on 29 June 2023, over 1 year ago
Updated 16 August 2024, 3 months ago

Problem/Motivation

When linking a node in Ckeditor using the module, the resulting /node/123 path does not get replaced with the url alias '/hello-world" while saving the node with the Linkit it filter enabled.

Steps to reproduce

Open a content type with a linkit CKE profile and filter enabled.
Link a random word or centence
Save the node

Expectation:
See node/123 being replaced with /hello-world, the url alias of node 123.

Current behavior:
node/123 does not get replaced with the effective url alias.

Vladt has mentioned this in a related issue and i thought this issue requires some more insights.

Vladt's comment:

I'm encountering an issue after applying patch #50 to Linkit 6.0.0-rc1 (as well as Linkit 5.0-beta 13), the data-entity-substitution, data-entity-type, data-entity-uuid attributes are no longer being added to the link, so the LinkitFilter is no longer working.

This seems to be happening because $href !== $href_dirty_check on line 129 of linkit.module is unsetting the values.

Source: https://www.drupal.org/project/linkit/issues/2877535#comment-15119360 Show URL alias after autocomplete selection instead of internal route (e.g., /node/123) Needs work

I myself are not using any patches, just a clean module base.

🐛 Bug report
Status

Closed: duplicate

Version

7.0

Component

Code

Created by

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

Comments & Activities

  • Issue created by @demon326
  • 🇺🇸United States mark_fullmer Tucson
  • Status changed to Postponed: needs info about 1 year ago
  • 🇺🇸United States mark_fullmer Tucson

    Thanks for reporting this. Can you clarify whether this is describing a shortcoming in the proposed change in 🐛 Direct URL to media file entity does not work because relative URL does not pass URL path validation Fixed , or in the current behavior of the module?

    When I test the current, development version of the module, I am seeing the URL alias rendered as the hyperlink when viewing a page.

  • 🇮🇳India iyyappan.govind Chennai, India

    @mark_fullmer,

    Thank you for the excellent module.

    I've tested this issue on my local environment. I noticed that the URL alias is visible on the node view page. It seems that this conversion is being facilitated by the Filter plugin. However, in cases of Headless or decoupled architecture, the Canonical URL pattern may still be displayed. This is because the canonical URL is stored strongly in the database.

    I believe it is necessary to save the URL alias directly in the database instead of canonical URL.

    Thanks

  • Status changed to Active 3 months ago
  • 🇮🇳India iyyappan.govind Chennai, India
  • Status changed to Closed: duplicate 3 months ago
  • 🇺🇸United States mark_fullmer Tucson

    I believe it is necessary to save the URL alias directly in the database instead of canonical URL.

    Doing this would have problematic impacts. What happens when the URL alias is updated on the referenced node? If there is no redirect in place, the referencing link would become broken.

    As further rationale that the canonical URL should be stored, Drupal core always stores the canonical URL in its database tables, as does the widely-used pathauto module.

    Re-reading this issue description, I conclude that it is not describing a bug in the module, but rather, it is a feature request that can be described as the following User Story:

    As a content editor, when I use the link autocomplete functionality, I want to see the URL alias in the editing interface rather than the canonical URL so that it is easier for me to see what the link pertains to.

    Note that this user story is distinct from rendering the URL alias to the site visitor on page render, which this module already does.

    As such, this is not a bug report, but a feature request and is in effect a duplicate of Show URL alias after autocomplete selection instead of internal route (e.g., /node/123) Needs work .

    Therefore, I'm going to mark this issue as a duplicate. If this analysis/conclusion is missing something, please explain!

Production build 0.71.5 2024