Need relative URLs for uploaded images

AI-generated summary

The discussion revolves around the need for relative URLs for uploaded images in Discourse. widepeer initiated the conversation, explaining the issue with full URLs in <img> tags when accessing the site over both HTTPS and a TOR .onion hidden service. They proposed modifying the URL generation to produce relative URLs.

sam acknowledged the issue and suggested that internal changes would be required, potentially involving a conditional check for CDN configuration. widepeer expanded on this idea, suggesting that setting Discourse.cdn_url_no_prefix to an empty string when no CDN is configured could achieve the desired result.

mreach and robbie.morrison expressed their support for relative URLs, sharing their own experiences with domain changes and the need for more flexibility in URL generation. codinghorror countered that a targeted search-and-replace operation can usually resolve issues with domain changes, but others argue that relative URLs would simplify this process.

There is a sympathetic ear from sam, who implied that implementation might be possible in the future.

How can I get Discourse to generate relative URLs for uploaded images?

I have a site that is available over HTTPS and a TOR .onion and I need a way to get images working for both.

How can I configure Discourse so that upload:// URLs are converted to relative URLs in the <img> tag? Where (which source file) does this URL generation take place?

I don’t think relative image URLs is a supported configuration, and that might be a very difficult change cc @sam

Just to clarify:

Uploading works correctly both from the HTTPS domain and the TOR hidden service .onion but the actual HTML generated for a post uses a full URL which is a problem.

I’m assuming somewhere there is some code that does something like

 '<img src="' + Discourse.base_url_no_prefix + '/uploads/....jpg' + '">'

and I need it to generate

 '<img src="' + '/uploads/....jpg' + '">'

Would playing with absolute_without_cdn be too low-level and affect too many things?

The URL needs to be relative because:

  • A normal browser cannot access the .onion URL.
  • Cannot access the normal site over TOR because it is behind DDoS protection. And even if it worked, I don’t want to leak details to TOR exit nodes.

This would require some internal changes, I am somewhat sympathetic cause it makes life a bit easier when changing domain names for sites that do not use A CDN.

Would have to be something like, IF no CDN configured then cook a relative url.

I assume you only need to set this up when the configuration is changed?

Imagine having

'<img src="' + Discourse.cdn_url_no_prefix + '/uploads/....jpg' + '">'

When there is no CDN configured then Discourse.cdn_url_no_prefix can simply be a empty string.

Does that mean that there is a chance you can implement this in the (near) future?

Just to add a voice and to agree with @sam, we’ve already had some switcheroos with our domains and relative URLs is most certainly needed.

I would like to add my voice in favor of relative internal links. I currently use full URLs to reference, for example, another topic on the same site.

Indeed, our site recently switched domains (noting that redirection is currently active):

And our new host, Communiteq (formerly DiscourseHosting), kindly somehow sedded our database to reflect this change.

Maybe there are technical reasons for the current status? Maybe we can use something like  %{THIS}/t/000  in the future? As a developer, absolute paths usually make me nervous. There is also the question of switching from http: to https: which we also undertook (or at least enforced more strictly) as part of the aforementioned migration. This looks like much the same use case as @mreach

As always, many thanks to the discourse team for a wonderful product. R.

It’s not usually a big deal to run a targetted search-and-replace on all affected posts when the domain changes.