markdown image links are wrong if repo is called 'src' #26548
Comments
|
Fixed with #26745 |
lunny
pushed a commit
that referenced
this issue
Jan 15, 2024
Fixes #26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details> --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
KN4CK3R
added a commit
to KN4CK3R/gitea
that referenced
this issue
Jan 15, 2024
Fixes go-gitea#26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details>
lunny
pushed a commit
that referenced
this issue
Jan 16, 2024
Backport #26745 Fixes #26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details>
fuxiaohei
pushed a commit
to fuxiaohei/gitea
that referenced
this issue
Jan 17, 2024
Fixes go-gitea#26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details> --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
henrygoodman
pushed a commit
to henrygoodman/gitea
that referenced
this issue
Jan 31, 2024
Fixes go-gitea#26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details> --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
silverwind
pushed a commit
to silverwind/gitea
that referenced
this issue
Feb 20, 2024
Fixes go-gitea#26548 This PR refactors the rendering of markup links. The old code uses `strings.Replace` to change some urls while the new code uses more context to decide which link should be generated. The added tests should ensure the same output for the old and new behaviour (besides the bug). We may need to refactor the rendering a bit more to make it clear how the different helper methods render the input string. There are lots of options (resolve links / images / mentions / git hashes / emojis / ...) but you don't really know what helper uses which options. For example, we currently support images in the user description which should not be allowed I think: <details> <summary>Profile</summary> https://try.gitea.io/KN4CK3R  </details> --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
|
Automatically locked because of our CONTRIBUTING guidelines |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Ack, this is an edge case.
We have a repo called src, and amazingly all links to images in markdown are wrong (404).
for example:
document: https://host/org/src/src/commit/...
actual img src: https://host/org/media/src/commit/...
expected img src: https://host/org/src/media/commit/...
It looks like the the first, instead of the second. occurrence of "src" is replaced by "media".
try.gitea.io
suspected location
Gitea Version
1.19.3
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
docker
Database
None
The text was updated successfully, but these errors were encountered: