[Feature Request] Permanent Link to Shelves, etc #1450

New Issue

OVERLORD · 2026-02-05T00:56:15+03:00

OVERLORD commented

2026-02-05 00:56:15 +03:00

Originally created by @mark-pippin on GitHub (Nov 15, 2019).

I'm looking to integrate (by way of link to bookstackapp) with existing systems. However, I do not want to trust users to not accidentally or intentionally change shelf names, etc.

Thus, I really need a static / permanent link to a shelf, etc. I would attempt this modification myself, but I'm not a php guy. That said, with brief guidance, I'd be willing to take a shot at it (having plenty of web app/mysql/linux experience, I just prefer python+flask for my utility apps I build).

Originally created by @mark-pippin on GitHub (Nov 15, 2019). I'm looking to integrate (by way of link to bookstackapp) with existing systems. However, I do not want to trust users to not accidentally or intentionally change shelf names, etc. Thus, I really need a static / permanent link to a shelf, etc. I would attempt this modification myself, but I'm not a php guy. That said, with brief guidance, I'd be willing to take a shot at it (having plenty of web app/mysql/linux experience, I just prefer python+flask for my utility apps I build).

OVERLORD added the 🔨 Feature Request 🏭 Back-End labels 2026-02-05 00:56:15 +03:00

OVERLORD commented

2026-02-05 00:56:24 +03:00

@joveice commented on GitHub (Mar 6, 2020):

@ssddanbrown Do you have a preference on how you would like this to be done or should I just give it a shot and make a PR?

@joveice commented on GitHub (Mar 6, 2020): @ssddanbrown Do you have a preference on how you would like this to be done or should I just give it a shot and make a PR?

OVERLORD commented

2026-02-05 00:56:31 +03:00

@ssddanbrown commented on GitHub (Mar 6, 2020):

@joveice Pages already have permalink ability, using the URL format of /link/<page_id>.
I think we should kind of follow this as close of possible so:

/link/shelf/<id>
/link/book/<id>
/link/chapter/<id>

In terms of UI, I like to keep power-user features hidden by default if possible but I think it'll be more trouble than its worth jamming this into some existing UI element, So maybe just a Permalink link at the bottom of the details panel will suffice, For power-users to right-click > copy link on.

Back-end logic should just match pages, Will need tests to cover the functionality.

@ssddanbrown commented on GitHub (Mar 6, 2020): @joveice Pages already have permalink ability, using the URL format of `/link/<page_id>`. I think we should kind of follow this as close of possible so: ``` /link/shelf/<id> /link/book/<id> /link/chapter/<id> ``` In terms of UI, I like to keep power-user features hidden by default if possible but I think it'll be more trouble than its worth jamming this into some existing UI element, So maybe just a `Permalink` link at the bottom of the details panel will suffice, For power-users to right-click > copy link on. Back-end logic should just match pages, Will need tests to cover the functionality.

OVERLORD commented

2026-02-05 00:56:32 +03:00

@joveice commented on GitHub (Mar 6, 2020):

@ssddanbrown Okey, I will take a look on that. I think a button on the right side with "Copy permanent link" would be a good option (have it open a popup with the link to copy). This is close to what Confluence from Atlassian does which I find quite useful.
But then I would also suggest that we add this link to be used with the insert link in the WYSIWYG.

@joveice commented on GitHub (Mar 6, 2020): @ssddanbrown Okey, I will take a look on that. I think a button on the right side with "Copy permanent link" would be a good option (have it open a popup with the link to copy). This is close to what Confluence from Atlassian does which I find quite useful. But then I would also suggest that we add this link to be used with the insert link in the WYSIWYG.

OVERLORD commented

2026-02-05 00:56:36 +03:00

@jakubboucek commented on GitHub (Jul 28, 2021):

This is very important feature to implement.

Currently our users are very frustrated to link pages together, because any small change (fix typo in page name, move page, rename book or shelve) make links structure unstable and broken.

I prefer to primary create internal link (thants means for links inside one BookStack instance) with persistent IDs.

Alternative way is analogy to WordPress URL management which is very robust to standard user's flow:

every page is saved own slug on first publish of page,
slug is no changed when page is renamed,
user can manually change slug (it's explicitly action in UI, here user can be notified about side effect of slug modification),
page slug is globally unicate over whole WordPress instance,
URL part of parent segments (chapter, book, shelves) are only cosmetic, can be invalid or completely omitted, only page's slug is used to define specifics page – invalid parent segment are only rebuilded and redirected to preferred format to ensure right canonicalization.
when user change slug on page, WordPress is keep previous one to redirect users to new one (until that slug was not used by another page).

This is fully compatible with the principles communicated by @ssddanbrown at: https://github.com/BookStackApp/BookStack/issues/2374#issuecomment-729661891

But the easiest and fastest for simple access is add one button Get persistent link which allow users direct way to get/copy permalink.

@jakubboucek commented on GitHub (Jul 28, 2021): **This is very important feature to implement.** Currently our users are very frustrated to link pages together, because any small change (fix typo in page name, move page, rename book or shelve) make links structure unstable and broken. I prefer to primary create internal link (thants means for links inside one BookStack instance) with persistent IDs. Alternative way is analogy to WordPress URL management which is very robust to standard user's flow: - every page is saved own `slug` on first publish of page, - `slug` is no changed when page is renamed, - user can manually change `slug` (it's explicitly action in UI, here user can be notified about side effect of `slug` modification), - page `slug` is globally unicate over whole WordPress instance, - URL part of parent segments (chapter, book, shelves) are only cosmetic, can be invalid or completely omitted, only page's `slug` is used to define specifics page – invalid parent segment are only rebuilded and redirected to preferred format to ensure right canonicalization. - when user change `slug` on page, WordPress is keep previous one to redirect users to new one (until that `slug` was not used by another page). This is fully compatible with the principles communicated by @ssddanbrown at: https://github.com/BookStackApp/BookStack/issues/2374#issuecomment-729661891 But the easiest and fastest for simple access is add one button `Get persistent link` which allow users direct way to get/copy permalink.

OVERLORD commented

2026-02-05 00:56:39 +03:00

@yene commented on GitHub (Jul 13, 2023):

Also here to give my plus one for slug feature. We renamed a book and it broke the links.

@yene commented on GitHub (Jul 13, 2023): Also here to give my plus one for `slug` feature. We renamed a book and it broke the links.

OVERLORD commented

2026-02-05 00:56:41 +03:00

@Coros commented on GitHub (Sep 13, 2023):

commenting to add our desire for a permanent/hashed link feature. We're migrating from Confluence and are already starting to see issues linking between pages. If a page title or book name is changed, everything falls apart.

@Coros commented on GitHub (Sep 13, 2023): commenting to add our desire for a permanent/hashed link feature. We're migrating from Confluence and are already starting to see issues linking between pages. If a page title or book name is changed, everything falls apart.

OVERLORD commented

2026-02-05 00:56:42 +03:00

@Man-in-Black commented on GitHub (Sep 13, 2023):

I made the experience that the links are changed automatically if I rename a book or page.
Other than that there is a button in the settings regenerate the index if it is corrupt.

@Man-in-Black commented on GitHub (Sep 13, 2023): I made the experience that the links are changed automatically if I rename a book or page. Other than that there is a button in the settings regenerate the index if it is corrupt.

OVERLORD commented

2026-02-05 00:56:47 +03:00

@avmaksimov commented on GitHub (Jun 14, 2024):

It's very needed thing. May be better to create an option what use in URI. And alternative way is to copy URI from a button on top of each page.
But for us is better a permanent link because we can often rename an article.

@avmaksimov commented on GitHub (Jun 14, 2024): It's very needed thing. May be better to create an option what use in URI. And alternative way is to copy URI from a button on top of each page. But for us is better a permanent link because we can often rename an article.

OVERLORD commented

2026-02-05 00:56:49 +03:00

@jamsix commented on GitHub (Jul 27, 2024):

One of the most organic ways to implement this is to have a system of "old link redirects". The way it works is:

System allows the URL of the resource (shelf/book/page) to be changed at any time, either by user, or - as it currently is - automatically by the app when title changes.
When the URL is changed, an entry is added to "redirects" database including the old and the new URL and a timestamp.
When a user visits a URL, the app first checks if there is a currently active content on that URL (as it does now). If it is not, the app loks into "redirects" database and if it find the URL in it, it 301 redirects the user to the new URL.

Current content always has precedense over historic URLs, so the system doesn't prevent new content to reuse retired URLs, while organicly keeping as many old URLs alive as possible. 301 redirects ensures search engines update content to new URLs.

@jamsix commented on GitHub (Jul 27, 2024): One of the most organic ways to implement this is to have a system of "old link redirects". The way it works is: 1. System allows the URL of the resource (shelf/book/page) to be changed at any time, either by user, or - as it currently is - automatically by the app when title changes. 2. When the URL is changed, an entry is added to "redirects" database including the old and the new URL and a timestamp. 3. When a user visits a URL, the app first checks if there is a currently active content on that URL (as it does now). If it is not, the app loks into "redirects" database and if it find the URL in it, it 301 redirects the user to the new URL. Current content always has precedense over historic URLs, so the system doesn't prevent new content to reuse retired URLs, while organicly keeping as many old URLs alive as possible. 301 redirects ensures search engines update content to new URLs.

OVERLORD commented

2026-02-05 00:56:52 +03:00

@donlencho commented on GitHub (Oct 6, 2025):

Keeping the same updated URLs system as now but adding a "permalink" ID to each element seems the simplest and would be quite user-friendly, with a "Share" Action, for instance, that would just copy the ID link.
This is similar to how NextCloud, MS Sharepoint, and others do it.

@donlencho commented on GitHub (Oct 6, 2025): Keeping the same updated URLs system as now but adding a "permalink" ID to each element seems the simplest and would be quite user-friendly, with a "Share" Action, for instance, that would just copy the ID link. This is similar to how NextCloud, MS Sharepoint, and others do it.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1450