Better link control through relative and stable links. #3347

New Issue

OVERLORD · 2026-02-05T06:25:58+03:00

OVERLORD commented

2026-02-05 06:25:58 +03:00

Originally created by @YoSiJo on GitHub (Nov 16, 2022).

Describe the feature you'd like

Describtion

Currently Bookstack Links, when using the insertLink button, writes like this:

[example](https://example.com/books/book/page/example)

Now I would like it if there were two ways to change this.

Used relative links

So that these then look like the following:

[example](/books/book/page/example)

Used stable link referencing

So that these then look like the following:

[example](https://example.com/link/79)

OR

[example](/link/79)

Note

For both options, it would be great to be able to control them similarly to the "Editor" choice.
So globally set a default but if necessary can adjust per page.

Describe the benefits this would bring to existing BookStack users

Currently, renaming a headline is enough to invalidate a link.
Adjusting the domain is also sufficient.
The latter is probably rather rare, but can also happen with multiple domains.

If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously.

Can the goal of this request already be achieved via other means?

Yes; Manual editing and not using the insertLink function. ;)

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?

6 months to 1 year

Additional context

There is a weak connection to #1342.
Roof here the issue is addressed by the APP_URL, not by functionalities of insertLink.

Ps. All this is under the Markdown editor. I have never seen or used the other W… editor.

Originally created by @YoSiJo on GitHub (Nov 16, 2022). ### Describe the feature you'd like ## Describtion Currently Bookstack Links, when using the `insertLink` button, writes like this: ```markdown [example](https://example.com/books/book/page/example) ``` Now I would like it if there were two ways to change this. ### Used relative links So that these then look like the following: ```markdown [example](/books/book/page/example) ``` ### Used stable link referencing So that these then look like the following: ```markdown [example](https://example.com/link/79) ``` OR ```markdown [example](/link/79) ``` ## Note For both options, it would be great to be able to control them similarly to the "Editor" choice. So globally set a default but if necessary can adjust per page. ### Describe the benefits this would bring to existing BookStack users Currently, renaming a headline is enough to invalidate a link. Adjusting the domain is also sufficient. The latter is probably rather rare, but can also happen with multiple domains. If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously. ### Can the goal of this request already be achieved via other means? Yes; Manual editing and not using the `insertLink` function. ;) ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundemental request ### How long have you been using BookStack? 6 months to 1 year ### Additional context There is a weak connection to #1342. Roof here the issue is addressed by the APP_URL, not by functionalities of `insertLink`. Ps. All this is under the Markdown editor. I have never seen or used the other W… editor.

OVERLORD added the 🔨 Feature Request label 2026-02-05 06:25:58 +03:00

OVERLORD closed this issue

2026-02-05 06:26:04 +03:00

OVERLORD commented

2026-02-05 06:26:06 +03:00

@ssddanbrown commented on GitHub (Nov 16, 2022):

Thanks for the request @YoSiJo but to be honest my feelings to relative/dynamic links remain much as the same as my common on 1342 in respect to growing fond of standardising on absolute links. In addition, this requests options and optional behaviour to a sub-component, which I usually try to avoid in the platform with relatively large benefit.

In regards to the described benefits, content renaming should be handled for most common scenarios where absolute URLs are used, on recent versions of BookStack. For domain adjustment, we provide a helper command to make such changes, again helped by the use of absolute URLs.

If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously.

Not really sure what is meant there. Either absolute or relative URLs can introduce scenarios to handle for the export formats, but from my experience absolute URLs are less prone to break as links, and generally allow a level of portability that relative links don't by default.

While page permalinks are available, I've never been too fond of these and generally try to focus on using, and improving where possible, the normal content links.

@ssddanbrown commented on GitHub (Nov 16, 2022): Thanks for the request @YoSiJo but to be honest my feelings to relative/dynamic links remain much as the same [as my common on 1342](https://github.com/BookStackApp/BookStack/issues/1342#issuecomment-592756293) in respect to growing fond of standardising on absolute links. In addition, this requests options and optional behaviour to a sub-component, which I usually try to avoid in the platform with relatively large benefit. In regards to the described benefits, content renaming should be handled for most common scenarios where absolute URLs are used, on recent versions of BookStack. For domain adjustment, we provide a helper command to make such changes, again helped by the use of absolute URLs. > If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously. Not really sure what is meant there. Either absolute or relative URLs can introduce scenarios to handle for the export formats, but from my experience absolute URLs are less prone to break as links, and generally allow a level of portability that relative links don't by default. While page permalinks are available, I've never been too fond of these and generally try to focus on using, and improving where possible, the normal content links.

OVERLORD commented

2026-02-05 06:26:16 +03:00

@YoSiJo commented on GitHub (Nov 17, 2022):

Thanks for the request @YoSiJo but to be honest my feelings to relative/dynamic links remain much as the same as my common on 1342 in respect to growing fond of standardising on absolute links. In addition, this requests options and optional behaviour to a sub-component, which I usually try to avoid in the platform with relatively large benefit.

When specifying relative links, the links in the processed format remain absolute.

[example](/books/book/page/example) -> https://example.com/books/book/page/example

Absolute left would therefore come out.

In regards to the described benefits, content renaming should be handled for most common scenarios where absolute URLs are used, on recent versions of BookStack. For domain adjustment, we provide a helper command to make such changes, again helped by the use of absolute URLs.

I have forgotten one advantage. The spelling is of course much shorter. Depending on the length of the FQDN, this can make a huge difference. Extreme cases are of course onion domains, but also a classic domain can become long.

Example:

This is an example sentence that references [A](https://bookstack.example.com/books/book/page/A) internally, in the context of [B](https://bookstack.example.com/books/book/page/B), which has an effect on [C](https://bookstack.example.com/books/book/page/C) and therefore needs to be considered in [D](https://bookstack.example.com/books/book/page/D).

This is an example sentence that references [A](/link/1) internally, in the context of [B](/link/2), which has an effect on [C](/link/3) and therefore needs to be considered in [D](/link/4).

The difference is already not small.

If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously.

Not really sure what is meant there. Either absolute or relative URLs can introduce scenarios to handle for the export formats, but from my experience absolute URLs are less prone to break as links, and generally allow a level of portability that relative links don't by default.

Since relative links specified in Markdown are nevertheless output absolutes, the point is moot.

While page permalinks are available, I've never been too fond of these and generally try to focus on using, and improving where possible, the normal content links.

The page permalink stabilizes the referencing immensely, in my estimation. Since so correcting a page title should not be able to break anything.

@YoSiJo commented on GitHub (Nov 17, 2022): > Thanks for the request @YoSiJo but to be honest my feelings to relative/dynamic links remain much as the same [as my common on 1342](https://github.com/BookStackApp/BookStack/issues/1342#issuecomment-592756293) in respect to growing fond of standardising on absolute links. In addition, this requests options and optional behaviour to a sub-component, which I usually try to avoid in the platform with relatively large benefit. When specifying relative links, the links in the processed format remain absolute. `[example](/books/book/page/example)` -> `https://example.com/books/book/page/example` Absolute left would therefore come out. > In regards to the described benefits, content renaming should be handled for most common scenarios where absolute URLs are used, on recent versions of BookStack. For domain adjustment, we provide a helper command to make such changes, again helped by the use of absolute URLs. I have forgotten one advantage. The spelling is of course much shorter. Depending on the length of the FQDN, this can make a huge difference. Extreme cases are of course onion domains, but also a classic domain can become long. Example: ```markdown This is an example sentence that references [A](https://bookstack.example.com/books/book/page/A) internally, in the context of [B](https://bookstack.example.com/books/book/page/B), which has an effect on [C](https://bookstack.example.com/books/book/page/C) and therefore needs to be considered in [D](https://bookstack.example.com/books/book/page/D). ``` ```markdown This is an example sentence that references [A](/link/1) internally, in the context of [B](/link/2), which has an effect on [C](/link/3) and therefore needs to be considered in [D](/link/4). ``` The difference is already not small. > > If you write the links with now so and if necessary the export understands relative or absolute links and can convert, that stabilizes the links enormously. > > Not really sure what is meant there. Either absolute or relative URLs can introduce scenarios to handle for the export formats, but from my experience absolute URLs are less prone to break as links, and generally allow a level of portability that relative links don't by default. Since relative links specified in Markdown are nevertheless output absolutes, the point is moot. > While page permalinks are available, I've never been too fond of these and generally try to focus on using, and improving where possible, the normal content links. The page permalink stabilizes the referencing immensely, in my estimation. Since so correcting a page title should not be able to break anything.

OVERLORD commented

2026-02-05 06:26:19 +03:00

@ssddanbrown commented on GitHub (Nov 17, 2022):

Relative links are not processed to absolute links by BookStack, apart from some edge-case scenarios such as exports. They will appear resolved to the absolute URL by the browser, for which the resultant URL will change depending on baseURL & subpath, and protocol.

I'm going to close this off in deferment to #1342, since I see that as the main issue for supporting relative URLs, whereas this is this issue is a dependant of that in a way.

If having shorter links in markdown is very much valuable to you feel free to open a feature request focused on that, but please focus it on the core value/user-benefit rather than describing any form of technical implementation/solution.

@ssddanbrown commented on GitHub (Nov 17, 2022): Relative links are not processed to absolute links by BookStack, apart from some edge-case scenarios such as exports. They will appear resolved to the absolute URL by the browser, for which the resultant URL will change depending on baseURL & subpath, and protocol. I'm going to close this off in deferment to #1342, since I see that as the main issue for supporting relative URLs, whereas this is this issue is a dependant of that in a way. If having shorter links in markdown is very much valuable to you feel free to open a feature request focused on that, but please focus it on the core value/user-benefit rather than describing any form of technical implementation/solution.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3347