Type/size appending not working

Created on 10 October 2023, about 1 year ago
Updated 17 October 2023, about 1 year ago

Problem/Motivation

Type/size appending is not working for media file links after upgrading from Drupal 9.5.11 to 10.1.x.

Steps to reproduce

  1. Drupal 10.1.4
  2. PHP 8.2
  3. CKEditor 5
  4. Configure file links for a direct, redirect, or binary response (none work).
  5. Select the CKEditor WYS field type for parsing.
  6. Link text to a file media entity in the WYS field, review front-end to confirm type/size has not been appended.

Various characters in the type/size appending settings have been tried. All other functions of the module seem functional after upgrading to Drupal 10.1.x. We are using LinkIt in our CKEditor 5 configurations. Image media entity links may also be impacted.

We are not seeing any console or watchdog log errors to trace.

This is a very helpful module function that a11y conscious content authors benefit greatly from. Any help restoring the type/size appending functionality would be greatly appreciated. Let me know if further information is needed.

Proposed resolution

Patch/update module so that media links in selected WYS field types, regardless if a direct, redirect or binary response should be parsed with type/text appended, as was working in Drupal 9.5.x.

πŸ› Bug report
Status

Closed: duplicate

Version

1.0

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada rjhammond

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

Comments & Activities

  • Issue created by @rjhammond
  • πŸ‡ΊπŸ‡ΈUnited States afinnarn

    Hello @rjhammond,

    I'm still getting my bearings on this codebase, but I just tested on 1.0.2, Drupal 10.1.4, and PHP 8.2 where I do see type and size appending working on the link fields but not in the "content parsing" when I tested on a file media item. I set it to "Redirection" for delivery.

    However, I figured out the issue with content parsing, or at least what I'm seeing.

    In the "MediaLinkEnhancementsAlterLinks" class, there is a method called "alterLinks". In that method around line #151, there is a function call to get the HTML of the full link so it can be checked in replacement further down in the code.

    // Get the full link to replace before we modify it.
    $full_link = $link->C14N();
    

    If you update that line to:

    // Get the full link to replace before we modify it.
    $full_link = $doc->saveHTML($link);
    

    The problem was the HTML attributes of the anchor tag were re-arranged by "$link->C14N()". So when the strings were compared in "$content = str_replace($full_link, $new, $content);" the anchor link didn't match exactly and the file extension wasn't added. With "$doc->saveHTML($link)" the attributes are in order so the content matches and is replaced.

    I will work on a MR for this, but if you can, please try changing that code to see if content parsing works.

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

    I errantly created an issue fork here, but I'm still not sure of your issue.

    Instead, I created another issue for what I mentioned with content parsing and made a MR here if you want to test: https://www.drupal.org/project/media_link_enhancements/issues/3394047 πŸ› Content parsing broken Needs review

  • πŸ‡¨πŸ‡¦Canada rjhammond

    Thank you very much @afinnarn!

    Your patch in #3394047 worked for me. I'm flagging this for closure as a duplicate of:
    https://www.drupal.org/project/media_link_enhancements/issues/3394047 πŸ› Content parsing broken Needs review

  • Status changed to Closed: duplicate about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States afinnarn

    Sounds good to me. I will close this issue as a duplicate.

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

    @rjhammond Can you review the duplicate issue, if you have time, so we can call it RTBC?

Production build 0.71.5 2024