Inconsistent links in Preview

[zmberber]

Currently, the file structure is as follows:

• Every article is in the root directory of the wiki's articles repository.
• An attachment attachment.xyz for an article article.md is located in article/attachment.xyz in that root directory.

For linking, we have the following:

• It is possible to link the article as [linktext](/article) and even [linktext](/article.md)
• It is possible to link the attachment as [linktext](/article/a/attachment.xyz)

Ideally, I would like to be able to link stuff consistently with how linking would work if I were to view the same markdown files in a text editor that can handle markdown links I made the following observations:

1. With articles, it is possible to link the article via [linktext](./article) and even [linktext](./article.md), but this is broken in preview mode.
2. With attachments, it is possible to them as [linktext](./article/a/attachment.xyz), but this is broken in preview mode, whereas [linktext](./a/attachment.xyz) works but only in preview mode while previewing the article article.
3. It is not possible to link attachments as [linktext](./article/attachment.xyz) or [linktext](/article/attachment.xyz).

(I hope that I didn't make any mistakes)

I suspect the reason for 1 (and the second part of 2) is that in preview mode, a relative path gets appended to the path of the article, which doesn't happen normally.

Also, filenames are automatically made lowercase in the underlying file structure, no matter the casing of the article name in the otterwiki viewer. I can imagine multiple reasons for this, but it might make linking stuff more confusing, since links could break when viewing the files in other markdown viewers that follow the link directly and are therefore case-sensitive. Also, where does otterwiki track how the casing is, if it can't see it in the filename? It seems weird to have extra metadata just for that.

So additionally to the preview bugs, I would personally heavily prefer it if links were made to be compatible with the file structure in a way that any other markdown viewer would handle it for relative paths.

Some thoughts:

• Make a folder and subfolder for article/a/ for each article and put attachments there? Or is that nonsensical?
• Have the attachments as it currently is, in the article folder, and have the path name for the http request also as it currently is with /a/ in the path name, but at least have linking work with links with a relative pathname ./article/attachment. The otterwiki viewer could just handle it however it likes, as long as the linking works.

I just want it to be consistent with viewing the markdown files in other settings.

[redimp]

I’m on the road. Can’t test with my mobile.

My guess: The wiki doesn’t know how to handle ./.

Can you please check if the following examples work as intended in both view and preview?

• a) [linktext](article)
• b) [linktext](article/a/attachment.xyz)
• c) [linktext](/article)
• d) [linktext](/article/a/attachment.xyz)

This maybe even a HTTP/HTML problem, since the markdown is just rendering the syntax to links.

[zmberber]

i have article1, article2, and attachment1 which is an attachment of article2

in article2, trying to view article1

preview

• a) goes to https://wiki.tld/article2/article1 and otterwiki says 404
• b) goes to https://wiki.tld/article2/article1/a/attachment1 and the webserver says 404
• c) works as intended
• d) works as intended

in the saved article

• a) works as intended
• b) works as intended
• c) works as intended
• d) works as intended

in article1, viewing article1 stuff

preview

• a) goes to https://wiki.tld/article1/article1 and otterwiki says 404
• b) goes to https://wiki.tld/article1/article1/a/attachment1 and the webserver says 404
• c) works as intended
• d) works as intended

in the saved article

• a) works as intended
• b) works as intended
• c) works as intended
• d) works as intended

[redimp]

The problem is, when viewing e.g. /Home. the links are relative to /. When previewing, the url is /Home/preview so the links are relative to /Home/.

I like the idea of having /path/to/Page with the modifiers, e.g. /preview or /edit or /history and would like to keep it this way.

SO the only chance to fix the links in the preview is to rewrite how the links in renderer.py are generated, because we can not use the mistune way anymore.

For the attachment routing, I have no idea how to get away from /Home/a/example.jpg and /Home/t/example.jpg, but we might have to change this with the upcoming subfolder/subpage feature that @marcrleonard is implementing. Please open a different feature request for this problem.

[zmberber]

ah that makes sense with the preview problem.

about attachment routing: that was supposed to be this issue! i just mentioned the preview problem on the side because i just noticed it (i should have done that one in a short seperate issue).

"inconsistent" was referring to it being inconsistent with the underlying file structure, and inconsistent with the way "normal" markdown viewers handle links.

[redimp]

Please open a second issue for the attachment routing and consider the discussion in #25

[redimp]

With the changes in the routing in a08b680 the issue with wrong links in Preview is fixed.

With the new feature of AutoRoute 7a7d7a4 you can link attachments of e.g. Home as
[linktext](Home/attachment.xyz). The old routes [linktext](Home/a/attachment.xyz) still work.