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.

| Comment | File | Size | Author |
|---|---|---|---|
| #10 | linkit-1845886-relative_url-10.patch | 2.38 KB | stefan.r |
| #9 | linkit-1845886-relative_url-9.patch | 1.29 KB | stefan.r |
| linkit-wysiwyg-process-wrong-url.png | 67.57 KB | Rob_Feature |
Comments
Comment #1
mrfelton commentedSame for me. Would be nice to see this working an a more robust way than using the full URL, which is subject to change.
Comment #2
anonThe 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.
Comment #3
Rob_Feature commentedSorry, 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?
Comment #4
anonHow 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?Comment #5
anonIf there is a way to insert a relative URI to a file, please let me know, or better, provide a patch.
Comment #6
mrfelton commentedI 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).
Comment #7
Rob_Feature commentedI think the best way forward (always) is to use existing functionality and tokens where they exist. These 3 options of embed methods would be:
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?
Comment #8
anonAs this works by design, I see this as a feature request now.
Comment #9
stefan.r commentedThis 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
Comment #10
stefan.r commentedThis makes it a configurable option as suggested in #7, allowing people to link to the file directly as opposed to linking to ie.
file/3Comment #11
stefan.r commentedWe 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.
Comment #12
stefan.r commentedFixed in the above issue
Comment #15
anonClosing again, the test bot change the status for some reason.