starred/wiki

Fork 0

mirror of https://github.com/requarks/wiki.git synced 2026-03-02 22:57:36 -05:00

Markdown links always server absolute #857

New issue

Open

opened 2026-02-20 15:24:43 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 15:24:43 -05:00

Owner

Originally created by @despens on GitHub (Nov 8, 2019).

Originally assigned to: @NGPixel on GitHub.

Describe the bug
It seems impossible to create relative links in markdown:

Current URL: http://localhost/this-doc
Markdown code [other doc in same folder](other-doc)
Rendered target URL: http://localhost/this-doc/other-doc

To Reproduce
Steps to reproduce the behavior:

Create two markdown documents in the same folder
Create links in between the documents referencing their names
Click on links

Expected behavior
It should be possible to use relative links to avoid having to type paths

Originally created by @despens on GitHub (Nov 8, 2019). Originally assigned to: @NGPixel on GitHub. **Describe the bug** It seems impossible to create relative links in markdown: Current URL: `http://localhost/this-doc` Markdown code `[other doc in same folder](other-doc)` Rendered target URL: `http://localhost/this-doc/other-doc` **To Reproduce** Steps to reproduce the behavior: 1. Create two markdown documents in the same folder 2. Create links in between the documents referencing their names 3. Click on links **Expected behavior** It should be possible to use relative links to avoid having to type paths

deekerman added the

bug

label

2026-02-20 15:24:43 -05:00

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@fengwang commented on GitHub (Feb 21, 2020):

@NGPixel Is there any plan to fix this bug?

I imported my old wiki, all files are in .md format and have tons of relative links such as [another link](./to_another_link) not correctly rendered.

@fengwang commented on GitHub (Feb 21, 2020): @NGPixel Is there any plan to fix this bug? I imported my old wiki, all files are in `.md` format and have tons of relative links such as `[another link](./to_another_link)` not correctly rendered.

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@eeshugerman commented on GitHub (Mar 28, 2020):

Relative links in Markdown do work, but there's definitely some weirdness. Though my experience is only with 2.x.

Weirdness in 2.x: say I'm editing a page at mywiki.com/foo/bar, and I want to link to mywiki.com/foo/bar/baz. In the markdown editor preview pane, the link only works if I do [Baz](bar/baz). But once the page is saved, the link only works if it is [Baz](baz).

The latter makes more more sense, imo, for a relative link. The editor preview pane should behave the same as the rendered page.

@eeshugerman commented on GitHub (Mar 28, 2020): Relative links in Markdown do work, but there's definitely some weirdness. Though my experience is only with 2.x. Weirdness in 2.x: say I'm editing a page at `mywiki.com/foo/bar`, and I want to link to `mywiki.com/foo/bar/baz`. In the markdown editor preview pane, the link only works if I do `[Baz](bar/baz)`. But once the page is saved, the link only works if it is `[Baz](baz)`. The latter makes more more sense, imo, for a relative link. The editor preview pane should behave the same as the rendered page.

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@RyanGreenup commented on GitHub (Jun 1, 2020):

yep I also just ran into this, relative links will work in the preview pane of the editor but not on the actual page.

relative links dont work at all for images.

this is an annoyance because the git synchronisation makes it so easy to work with content from within vim/emacs/atom but then on the page the links are broken.

@RyanGreenup commented on GitHub (Jun 1, 2020): yep I also just ran into this, relative links will work in the preview pane of the editor but not on the actual page. relative links dont work at all for images. this is an annoyance because the git synchronisation makes it so easy to work with content from within vim/emacs/atom but then on the page the links are broken.

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@tionis commented on GitHub (Jul 22, 2020):

This same problem also persists with linked pictures which reduces the portability of the markdown files greatly.

@tionis commented on GitHub (Jul 22, 2020): This same problem also persists with linked pictures which reduces the portability of the markdown files greatly.

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@hemberger commented on GitHub (Feb 26, 2021):

This is my experience with v2 as well. In v1, all my relative markdown links rendered correctly in HTML, so this seems like a pretty serious regression. The only thing that fixes this is to convert all relative links into absolute links, e.g.

subdir
|-> page1.md
\-> page2.md

If the contents of subdir/page1.md contain

[Link to page 2](page2)

then an incorrect link to https://mydomain/subdir/page1/page2 is rendered.

If I change subdir/page1.md to contain

[Link to page 2](/subdir/page2)

this renders the link correctly as https://mydomain/subdir/page2.

However, this solution isn't very portable, and since it's a regression from v1, all relative links need to be transformed before v2 is usable for me.

@NGPixel I see you labeled this as a bug back in 2019. Do you think the most likely outcome is to not support relative paths going forward, or is this something that you would like to see fixed given enough time and development resources? Maybe that's a silly question to ask, but I'm trying to gauge whether I should bite the bullet and convert all my markdown links, or, since I'm not in a rush to migrate to v2, give this issue some more time to soak. Thanks!

@hemberger commented on GitHub (Feb 26, 2021): This is my experience with v2 as well. In v1, all my relative markdown links rendered correctly in HTML, so this seems like a pretty serious regression. The only thing that fixes this is to convert all relative links into absolute links, e.g. ``` subdir |-> page1.md \-> page2.md ``` If the contents of `subdir/page1.md` contain ``` [Link to page 2](page2) ``` then an incorrect link to `https://mydomain/subdir/page1/page2` is rendered. If I change `subdir/page1.md` to contain ``` [Link to page 2](/subdir/page2) ``` this renders the link correctly as `https://mydomain/subdir/page2`. However, this solution isn't very portable, and since it's a regression from v1, all relative links need to be transformed before v2 is usable for me. @NGPixel I see you labeled this as a bug back in 2019. Do you think the most likely outcome is to not support relative paths going forward, or is this something that you would like to see fixed given enough time and development resources? Maybe that's a silly question to ask, but I'm trying to gauge whether I should bite the bullet and convert all my markdown links, or, since I'm not in a rush to migrate to v2, give this issue some more time to soak. Thanks!

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@despens commented on GitHub (Mar 13, 2021):

One of the great feats of wiki.js is that there is theoretically almost no lock-in when you stick with markdown and make use of the great backup features. This is basically the only issue that gives me headaches regarding portability. Some more advanced markdown features are different across platforms and "flavors", but how to make links is supposed to be agreed upon, see https://spec.commonmark.org/0.29/#links — anything that handles links differently from putting what's in the parentheses into the resulting link tag's href attribute is probably a special function that needs to be consciously enabled.

In the worst case, a link like [related info](details) would be pointing to /alice/details in wikijs and to /details in another markdown rendering system, for instance GitHub. This might wrongly represent the contents of the wiki and twist the meaning of the information structure.

I understand that some wikis have been built with this behavior already and it would be painful to migrate them to a different default behavior. Yet if wikijs would offer a "classic link rendering" option or the like, the problem could probably be mitigated?

@despens commented on GitHub (Mar 13, 2021): One of the great feats of wiki.js is that there is theoretically almost no lock-in when you stick with markdown and make use of the great backup features. This is basically the only issue that gives me headaches regarding portability. Some more advanced markdown features are different across platforms and "flavors", but how to make links is supposed to be agreed upon, see https://spec.commonmark.org/0.29/#links — anything that handles links differently from putting what's in the parentheses into the resulting link tag's `href` attribute is probably a special function that needs to be consciously enabled. In the worst case, a link like `[related info](details)` would be pointing to `/alice/details` in wikijs and to `/details` in another markdown rendering system, for instance GitHub. This might wrongly represent the contents of the wiki and twist the meaning of the information structure. I understand that some wikis have been built with this behavior already and it would be painful to migrate them to a different default behavior. Yet if wikijs would offer a "classic link rendering" option or the like, the problem could probably be mitigated?

deekerman commented

2026-02-20 15:24:45 -05:00

Author

Owner

@e4rthdog commented on GitHub (Mar 3, 2025):

Is this being discussed still? Relative paths make the whole procedure portable, we can use pandoc to generate pdf e.t.c. Cant maintain team documentation based on github repo, without relative paths working in markdown files.

@e4rthdog commented on GitHub (Mar 3, 2025): Is this being discussed still? Relative paths make the whole procedure portable, we can use pandoc to generate pdf e.t.c. Cant maintain team documentation based on github repo, without relative paths working in markdown files.