System user replaces wrong URL when it downloads local copy of image

(Gerhard Schlager) #1

Hmm, a bit off-topic, but did the system user replace the wrong image URL (within the code fences) after downloading the local copy?

That looks wrong to me.

Add setting to disable hotlinking of large image files
(Sam Saffron) #2

Yeah that is absolutely a bug, can you separate item on it?

(Sam Saffron) #3

I vaguely recall this was opened in the past with a status denied…

Honestly I do not think we should ever be mucking with raw and only apply this kind of magic to cooked. I think that is the root of this bug.

If we are mucking with raw fixing this is actually quite a giant headache cause we would need to do the replacement in a reverse markdown parser or hoist stuff using magics.

(Leo McArdle) #4

This looks like that:


I found one direct reference to this topic, but it was closed so I couldn’t piggyback off of it. I have some cases where the URL of an image is of minor significance, but certainly not of paramount importance. Overall, I prefer to have the nicety of locally cached images, but there’s a few cases where I’d like to escape that context especially in code blocks of specific posts.

Might there be a way to do it on a by-post or by-topic basis? How about a tag that or html component that tells that feature to ignore the post? This is certainly not a high priority thing and I wouldn’t spend a lot of cycles on it, I just thought I’d bring it up again to see if there may have been any architectural changes that makes this an easier fix.

The best workaround I’ve found is just to screenshot the text in it’s original form, but that of course doesn’t allow for easy copying from the code blocks.

(Joshua Rosenfeld) #7

Nice old bug report you dug up! I swear we have a more recent report of this that is still open and active, but I’m failing at search right now.

(Gerhard Schlager) #8

Are you including the image link two times? Once as normal link and once within a code block? If so, then it’s this bug.


I am linking twice, once in a code block and once as the real image. Both links are replaced with the same /uploads/default/.../... url

(Kane York) #10

The curious instance about this thread’s OP’s report is that the original image is nowhere in the post raw - it’s only in the embed.

(Tobias Eigen) #11

Yesterday I wrote up a little howto for using html to align images - love that little hack by @awesomerobot and my colleagues will be excited about it. However I noticed that in my code example the image urls got changed from to the local upload. Not a big deal in this case and I realize this is probably impossible to prevent but it seems unfortunate that a code example can be messed up like this automatically by discourse.

The only way to stop it I guess would be to disable the copy to local feature, which I definitely do not want to do. :slight_smile:

(Joshua Rosenfeld) #12

Moved your post here @tobiaseigen, sounds like the same issue (url in code block being replaced).

(Régis Hanol) #13

@nbianca can you make sure we never change URLs in code blocks? (We need to hoist code blocks before doing the search/replace)

(Jeff Atwood) #15

I remember this being exceedingly complicated, are we sure this isn’t a big risk? There’s a reason we avoided it until now…

(Sam Saffron) #17

Attempt #2 cause imgur was disabled at the time as a target:

I just hotlinked:

It is hotlinked :arrow_double_down:

I quoted it here:

And added an IMG tag here:

This is how the code for the post looks:

Attempt #2 cause imgur was disabled at the time as a target:

I just hotlinked:

It is hotlinked :arrow_double_down: 

<img src='//'>

I quoted it here:

And added an IMG tag here:

<img src='//'></img>

This is how the code for the post looks:

This is it in an inline code block

(Sam Saffron) #18

Yeah this is a nightmare level fix we basically need a reverse markdown parser to do this correctly, I do not want to take this on right now. One day … maybe… but not today.

(Régis Hanol) #20

My bad, since we added some hoisting I thought it was the same issue. Turns out, we added hoisting on the cooked version, not the raw version.

This is indeed a completely different level of :exploding_head:

(Jeff Atwood) #22

I wouldn’t even assign this, it can remain in our long term todos. It’s a rare case anyways.