File is inserted with absolute URL

Duplicate.

still the same.

Wont fix this in the 4.x bransh. This is fixed in the 5.x tho.

Hi @anon, sorry for coming back to this old issue, but it seems to be a problem also in current 8.x-5.0-beta12
I enabled linkit for normal files (NOT media!!). If I check the source in edit mode, the files are displayed with relative path:

<p><a data-entity-substitution="file" data-entity-type="file" data-entity-uuid="d97291bf-1278-4e4f-9cac-01216dc84683" href="/sites/default/files/media/document/2018-05/2015-02-23-001_Postkarte.pdf" title="DEV test PDF">TEST - DEV-Team&nbsp;(PDF)</a></p>

After saving the node, the relative URL is changed to absolute:

<p><a data-entity-substitution="file" data-entity-type="file" data-entity-uuid="d97291bf-1278-4e4f-9cac-01216dc84683" href="https://www.example.de/sites/default/files/media/document/2018-05/2015-02-23-001_Postkarte.pdf" title="DEV test PDF">TEST - DEV-Team&nbsp;(PDF)</a></p>

Because we use Drupal as headless system, we would need the path to be relative instead of an absolute path. Should this be fixed in 8.x-6 ?

Hi,

The issue seems to be in the substitution code. I'm using 8.x-5.0-beta13 version of Linkit so I don't know if this has been fixed in the 6.0 version.

In the file linkit/src/Plugin/Linkit/Substitution/Media.php and same in linkit/src/Plugin/Linkit/Substitution/File.php there exists this line of code,

$url->setGeneratedUrl(file_create_url($entity->getFileUri()));

This will get the absolute path to the media or file and for most this is not what you want since it will break if you change servers or use Varnish. In order to have Linkit use the relative path, that line of code needs to be changed to,

$url->setGeneratedUrl(file_url_transform_relative(file_create_url($file->getFileUri())));

This is the workaround I've been using but this is changing the core module code which isn't recommended. Hopefully this code change exists in version 6.0 (can anyone verify this?), if not it should be implemented.

Here is a quick patch for the ones looking for a solution to this issue.

Ran into this with 6.x when trying to link core media entities. I can confirm it is also still happening on 5.x as well.

@oldeb's patch fixes the issue. Happy to work on fixing the tests if it will help.

@johnnny83 looks like you are still assigned to this issue though.

First attempt at fixing tests.

Assigning myself for review, and setting the version this issue relates to as 6.0.x-dev, although I think we should backport it to 5.x for folks still using that version.

My main question about this issue is whether rendering the media/file URLs should always relative, or whether this is something that sites should be able to choose between this. This issue was originally entered as a "Feature request," but the issue description is more of a bug report.

For example, is there a scenario where Drupal media/file entities could be defined to have an external backend (such as AWS) where stripping the absolute path would cause those links to break? (To be clear, I'm not talking about plain URLs to external files, and this would be a pretty weird edge case.)

This issue also is related proposals about how media/file entity links should be rendered in #3078075: Detect and strip base URL from pasted URLs to increase matching hits and support multilingual, #3340174: Media substitution plugin renders absolute paths, and (maybe?) #3153482: Cutting off /edit for media path breaks entity detection, so I'd like to consider this in the context of those.

In particular, #3340174: Media substitution plugin renders absolute paths seems like it's solving the same underlying problem (it calls out this issue in the description, too).

Thoughts?

My main question about this issue is whether rendering the media/file URLs should always relative, or whether this is something that sites should be able to choose between this. This issue was originally entered as a "Feature request," but the issue description is more of a bug report.

For me it appeared to be a bug since the generated links were not using the correct base url and were breaking links to media files.

For example, is there a scenario where Drupal media/file entities could be defined to have an external backend (such as AWS) where stripping the absolute path would cause those links to break? (To be clear, I'm not talking about plain URLs to external files, and this would be a pretty weird edge case.)

I don't know enough of how different backends handle this, but would assume contrib modules like S3 File System or Azure Blob Storage File System already provide a way to configure this.

I think the S3 module has a Drupal slack channel. Maybe running the change past someone there might give more insight?

For me this definitely is in category "bugs". Drupal uses relative paths everywhere, most notably the media module itself uses relative paths for links to its file entities too.

If other contrib modules like AWS need absolute paths, this has to solved in their scope.

If other contrib modules like AWS need absolute paths, this has to solved in their scope.

That's more or less the conclusion I was coming too, as well. Better to follow convention of the Drupal media module itself.

Thanks for the feedback, folks!

I'm going to mark #3340174: Media substitution plugin renders absolute paths as a duplicate of this issue (its patch is outdated and is also not as comprehensive as this one), and just want to consider any possible implications for this change on #3078075: Detect and strip base URL from pasted URLs to increase matching hits and support multilingual. After that, I plan to merge this bugfix.

+++ b/src/Plugin/Linkit/Substitution/File.php
@@ -24,7 +24,7 @@ class File extends PluginBase implements SubstitutionInterface {
     $url = new GeneratedUrl();
     /** @var \Drupal\file\FileInterface $entity */
-    $url->setGeneratedUrl(\Drupal::service('file_url_generator')->generateAbsoluteString($entity->getFileUri()));
+    $url->setGeneratedUrl(\Drupal::service('file_url_generator')->generateString($entity->getFileUri()));
     $url->addCacheableDependency($entity);
     return $url;
   }

FWIW, a lot of this could be greatly simplified with $entity->createFileUrl(), which defaults to a relative path.

Bigger change for the patch, but easier code to maintain in the end.

Two notes:
* Core also switched to this in a several file/image formatters as part of #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it, there was a bit of a backlash on that, but in contexts that I think are less likely to be an issue for this module (RSS feeds and other API-ish responses)
* generateString() returns a non-absolute link *if possible*. If you have an external storage like AWS, use CDN/asset domain or anything like that then you can absolutely still make that absolute and point to wherever you want. There has been a hook for that since forever and the streamwrapper also controls this. So the risk of this should be minimal.

[switching to relative URLs for files is] less likely to be an issue for this module (RSS feeds and other API-ish responses)

I can imagine a reasonably plausible scenario where absolute URLs would be wanted: Drupal backend that hosts static files with a decoupled frontend that links to those files in content served by the backend & run through a text format filter. (With #2712951: Linkit for Link field added, this would also impact link fields using the Linkit formatter...)

But I don't think that it should be the responsibility of the Linkit text filter to support that. For folks that really do need absolute URLs in the context of what a Drupal text format filter renders, one solution could be to use https://drupal.org/project/pathologic, which supports specifying an absolute path.

So I agree that the impact of this change to relative URLs is manageable for folks who still want absolute URLs.

Somewhat related to #20 above, this patch combined with the patch in https://www.drupal.org/project/linkit/issues/2712951 does not allow for linking directly to files. I was about to post on 2712951 but then reinstalled without the patch from #13 – linking to files totally works now!

Thanks to everyone for your contributions here. So much amazing progress on this module already this year.

The attached patch uses Berdir's suggestion from #19 for simplifying the generation of the URL. Interdiff from the previous patch is included. This functionally checks out for me, and the relevant automated tests pass. Since Berdir said "Bigger change for the patch, but easier code to maintain in the end," I want to double-check that I'm not misinterpreting, since this seems not much of a "bigger change."

Separately, following up on:

does not allow for linking directly to files. I was about to post on 2712951 but then reinstalled without the patch from #13 – linking to files totally works now!

Thanks for the feedback, jds1. Can you elaborate a bit? I'm confused! What I'm hearing is that the proposed patch in this issue is preventing you from linking directly to files, and the implication, since you mention #2712951: Linkit for Link field, is that you're doing so from a link field using the Linkit autocomplete widget there. That isn't my result when I test this with the existing patch (I am using the 6.0.x branch, however, which includes the Linkit for Link field): I see an option to either link to the File entity or the Media entity from the Linkit autocomplete (in both CKEditor and in the Link field widget). If you're getting a different result, can you provide steps to reproduce? Thanks!

+++ b/src/Plugin/Linkit/Substitution/File.php
@@ -24,7 +24,7 @@ class File extends PluginBase implements SubstitutionInterface {
     $url = new GeneratedUrl();
     /** @var \Drupal\file\FileInterface $entity */
-    $url->setGeneratedUrl(\Drupal::service('file_url_generator')->generateAbsoluteString($entity->getFileUri()));
+    $url->setGeneratedUrl($entity->createFileUrl());

I meant a bigger conceptual/per line change. The previous patches essentially just changed generateAbsoluteString to generateString, this removes the file url generator service (or hides it within the method we call now in reality).

the result is the same and the patch file size is the same or even smaller, yes.

Alright, we now have relative URLs in rendered file paths!

If jds1 still has a scenario where this causes issues linking directly to files (#21), we can address that when more information is available.

Re #25, see #3354873: Direct URL to media file entity does not work because relative URL does not pass URL path validation, which seems to be a regression caused by this change.