search

requarks / wiki

Wiki.js | A modern and powerful wiki app built on Node.js
https://js.wiki
GNU Affero General Public License v3.0
24.34k stars 2.69k forks source link

Markdown links always server absolute #1201

Open despens opened 4 years ago

despens commented 4 years ago

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

fengwang commented 4 years ago

@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.

eeshugerman commented 4 years ago

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.

RyanGreenup commented 4 years ago

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.

tionis commented 4 years ago

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

hemberger commented 3 years ago

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!

despens commented 3 years ago

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?