Contrib.social

Linkit Link field: Double-encoded file links

Open on Drupal.org →
Created on 28 March 2024, 8 months ago

Problem/motivation

This is related to this closed issue 🐛 Linkit Link field: File entities not processed like other entities, resulting in double-encoding Fixed . We are encountering the issue of double-encoded links for file entities with 6.1.3 using the Linkit widget with a core formatter, in this case the Separate link text and URL formatter.

Steps to reproduce

  1. install Linkit 6.1.x-dev
  2. Upload a file/media with a space in the name
  3. Edit the basic page content type, add a link field with default settings but change the form display to use the linkit widget, change the display to use a non-linkit formatter like Separate link text and URL
  4. Create a page using the basic page content type and link to the file/media with the link field.
  5. On the edit page the link will appear like this: /sites/default/files/2023-03/name%20with%20space.pdf
  6. When the page is saved and viewed the link will appear like this: /sites/default/files/2023-03/name%2520with%2520space.pdf

Proposed resolution

If core link formatters expect a decoded url then it seems ideal that the Linkit widget should take care of decoding the url. I'm not sure if there is a better way to accomplish that but I am attaching a patch that adds an urldecode() step in MassageFormValues() in LinkWidget.

This module uses Gitlab CI for automated testing of proposed code changes. To contribute code changes, create a merge request. Patch files will not trigger automated testing and are not sufficient for review.
🐛 Bug report
Status

Active

Version

6.1

Component

Code

Created by

🇨🇦Canada laura.j.johnson@gmail.com Toronto

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

Comments & Activities

  • Issue created by @laura.j.johnson@gmail.com
  • Comment 8 months ago →
    🇨🇦Canada laura.j.johnson@gmail.com Toronto
  • Status changed to Needs review 8 months ago
  • Comment 8 months ago →
    🇺🇸United States vinmassaro
  • Comment 8 months ago →
    🇺🇸United States codechefmarc

    I was just trying out this patch and noticed that if there isn't a value passed to the urldecode function on line 220, it will give an error message about a required parameter. I suggest adding the following:
    $value['uri'] = $uri ? urldecode($uri) : ''; or $value['uri'] = $uri ? urldecode($uri) : NULL; - I haven't dug too deep into if the $value['uri] needs to be an empty string or a NULL.

  • Comment 8 months ago →
    🇨🇦Canada TheDuke13

    Here's a patch with the fix mentioned, encountered this issue with a site where we got a deprecation warning that passing NULL as parameter #1 to urldecode() triggers a deprecated warning, so checking to ensure it's not empty would be important.

  • Comment 6 months ago →
    🇺🇸United States mark_fullmer Tucson
  • Comment about 2 months ago →
    🇺🇸United States jeffam

    I ran into similar problems when users would paste URLs with spaces in them to PDFs in the file system.

    With the core link widget, when pasted, a link like http://www.example.com/sites/default/files/file name.pdf would be stored as http://www.example.com/sites/default/files/file%20name.pdf. When viewed, such a link would work fine.

    With the linkit widget, that same link would be stored as base:/sites/default/files/file%20name.pdf. When viewing, the links would be double-encoded, e.g. http://www.example.com/sites/default/files/file%2520name.pdf.

    From that I assume that the base: and internal: link schemes must expect non-urlencoded paths.

    Here's a patch that applies to 6.1.x and targets only the base: and internal: links.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024