[Feature Request] Permanent Link to Shelves, etc

[mark-pippin]

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

[joveice]

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

[ssddanbrown]

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

[joveice]

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

[jakubboucek]

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: #2374 (comment)

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

[yene]

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

[Coros]

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.

[Man-in-Black]

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.

[avmaksimov]

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.

[jamsix]

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.