Issue when linking to content with ampersands or single quotes in the title

I would like to propose an alternative suggestion based on the work in #3355004 which I will close as a duplicate issue.

Rather than removing escaping from the matcher plugin, we can handle the HTML clientside when inserting the value into the title field. This keeps the output from module correctly escaped. I believe it should be the responsibility of the thing using this data to correctly handle the escaped HTML.

No interdiff attached as this is an alternative approach.

The last submitted patch, 24: linkit-issue-linking-to-ampersands-2981543-24-test-only.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

I believe it should be the responsibility of the thing using this data to correctly handle the escaped HTML.

Typically the output layer does the escaping to prevent duplicate escaping. For reference see #2297711: Fix HTML escaping due to Twig autoescape →

I wasn't able to apply patch in #24 to the current 6.0.0 so here is a reroll.

#27 - apologies I missed your reply.

RE:

Typically the output layer does the escaping to prevent duplicate escaping. For reference see #2297711: Fix HTML escaping due to Twig autoescape

I agree with this - Drupal is still an output layer via the endpoint - and my suggestion is to keep the Drupal application escaping at the output layer.

I believe this is similar to how core handles autocompletes - e.g for a standard entity autocomplete the html is escaped by Drupal so that the JS just renders what it receives https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/autocomp...

The difference here is after rendering we are wanting to take something that is HTML back into a plain text context - which I believe we can do by getting the text content of the html element instead of removing any escaping from the backend.

I applied the patch in drupal 10.1.0 instance with linkit 6.1.0.
After applying the patch, it seems to be working fine . I have attached screenshots for the reference.

The difference here is after rendering we are wanting to take something that is HTML back into a plain text context - which I believe we can do by getting the text content of the html element instead of removing any escaping from the backend.

This rationale makes sense to me, and the resolution is significantly more comprehensible than the approach of removing escaping from the matcher.

I'll proceed to merge this into both the 6.0.x branch (compatible with Drupal 9.x through 10.0.x) and the 6.1.x (compatible with Drupal 10.1.x+).

Automatically closed - issue fixed for 2 weeks with no activity.