I'm aware of this issue, which claims to have fixed this almost 2 years ago: #1055638: Linkit inserts absolute URI to files

However, what I'm seeing is improper inserting of the URL of a file when chosen through the Linkit WYSIWYG button. The image below shows my process, which includes:

  • Setting my linkit profile to use the file:path as the result format
  • Choosing a file in the WYSIWYG previews the correct url/token to insert
  • When it's inserted, it shows the FULL url in the dialog, not the token I wanted
  • The final inserting into the WYSIWYG also shows the full URL.

CommentFileSizeAuthor
#10 linkit-1845886-relative_url-10.patch2.38 KBstefan.r
#9 linkit-1845886-relative_url-9.patch1.29 KBstefan.r
linkit-wysiwyg-process-wrong-url.png67.57 KBRob_Feature

Comments

mrfelton’s picture

mrfelton commented

Same for me. Would be nice to see this working an a more robust way than using the full URL, which is subject to change.

anon’s picture

anon
Primary language Swedish
Location Gothenburg
commented
Status: Active » Closed (works as designed)

The result format has nothing to do withthe URL.
That only shows extra information about the result. Nothing more.

Files have full urls as wrapper://someuri most be translated into a fully url.

Rob_Feature’s picture

Rob_Feature commented
Status: Closed (works as designed) » Active

Sorry, but reopening because I dont really understand the explanation...

I understand that the RENDERED result has nothing to do with linkit, and that's fine (I probably should have left out the last screenshot to avoid confusion). However, the urls are still FULL urls on the INPUT side (the node edit form).

Are you saying that, basically, linkit can't (and won't?) attempt to insert the tokenized url (ie. public://my-file-name.pdf) at all? It will always put in the full url and thats by design?

anon’s picture

anon
Primary language Swedish
Location Gothenburg
commented

How do you use the tokenized uri in the body text? You have to have somekind of uri-translator for that, right?
Just to insert a <a href="public://my-file-name.pdf">Lorem ipsum</a> wont work? Or am I missing something?

anon’s picture

anon
Primary language Swedish
Location Gothenburg
commented

If there is a way to insert a relative URI to a file, please let me know, or better, provide a patch.

mrfelton’s picture

mrfelton commented

I touched upon this in #1554940: Managed file support where I originally fixed up the Managed file support to use the full URL. One option would be to fix up #1647980: Use fid rather than stream wrapper. ad use the Portable Path module. Another option would be to use Media embed syntax.

But if I understand it correctly, this module supports tokens in the output format (looks that way from the above screenshots)? meaning that possibly the best thing to to would be to either create another module that could provide a token that represents some kind of permanent path to the managed file. Or, patch file_entity to provide such a token (probably the best idea).

Rob_Feature’s picture

Rob_Feature commented

I think the best way forward (always) is to use existing functionality and tokens where they exist. These 3 options of embed methods would be:

  • Media Module Format
  • File Entity Module Tokens (doesnt exist yet?)
  • Full URL (default)

So the linkit configs contain a selector with the options based on which modules are available. The user could select one of the 3 methods above (always defaulting and falling back to full url as it is now).

It seems the low hanging fruit would at least be to support media module in addition to full urls. The tokens already exist and are usable immediately.

Thoughts on this?

anon’s picture

anon
Primary language Swedish
Location Gothenburg
commented
Category: bug » feature

As this works by design, I see this as a feature request now.

stefan.r’s picture

stefan.r commented
Version: 7.x-2.x-dev » 7.x-3.x-dev
Category: Feature request » Bug report
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new linkit-1845886-relative_url-9.patch1.29 KB

This may have worked in the past but in 3.x HEAD this is still broken if not using Media/File Entity.

As to #7, at this point as URLs are created using entity_uri(). So if File Entity 2.x is installed, links will go to file/FILE ID. With Media 1.x + File Entity 1.x, links will go to media/FILE ID. In both of those cases there will be a relative URL, but if neither of those are installed, the URL callback for the Drupal core File module will create an absolute URL to the file itself.

Technically this may not be a "bug" in the Linkit module itself but a bug in drupal core as the file URL callback uses file_create_url, which can only create an absolute URL at this point, but realistically this is not going to be fixed there. So as per the maintainers suggestion in #5, I have attached a patch here :)

Related:
#837794: How can I convert a file uri to relative path?
#1554940: Managed file support
#1833614: Linkit always uses absolute urls (?)
#2163555: Linkit should use input filters and tokens instead of absolute links
#2158107: files: link inserted does not point to download but to entity page ("/file/FID" instead of "/system/files/FILEPATH")
#1352182: Media assets should have relative paths for wysiwyg editors

stefan.r’s picture

stefan.r commented
StatusFileSize
new linkit-1845886-relative_url-10.patch2.38 KB

This makes it a configurable option as suggested in #7, allowing people to link to the file directly as opposed to linking to ie. file/3

stefan.r’s picture

stefan.r commented

We could probably use the patch from #2158107: files: link inserted does not point to download but to entity page ("/file/FID" instead of "/system/files/FILEPATH") here instead as it is more complete.

stefan.r’s picture

stefan.r commented
Status: Needs review » Closed (duplicate)

Fixed in the above issue

The last submitted patch, 9: linkit-1845886-relative_url-9.patch, failed testing.

Status: Closed (duplicate) » Needs work

The last submitted patch, 10: linkit-1845886-relative_url-10.patch, failed testing.

anon’s picture

anon
Primary language Swedish
Location Gothenburg
commented
Status: Needs work » Closed (duplicate)

Closing again, the test bot change the status for some reason.