mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement] Custom URL paths for libraries #2408
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2408
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ahobsonsayers on GitHub (Dec 10, 2024).
Type of Enhancement
Server Backend
Describe the Feature/Enhancement
Currently libraries get given a random uuid when they are created. The uuid is then used in the url of library e.g. the library url will be
<base url of abs>/library/<uuid of library>It would be awesome if you could define (unique) human ids for libraries, so that they could be used in the url to make them more friendly.
e.g. I could give my library a human id of
audiobooksand then the url of the library would be<url of abs>/library/audiobooksWhy would this be helpful?
This would make urls much more readable and user-friendly - making it much easier to navigate directly to libraries by typing the url and identify the library from the url.
It is also useful of you want to recreate a library, and don't want all current links/bookmarks to the library it to break.
Future Implementation (Screenshot)
N/A
Audiobookshelf Server Version
V2.17.5
Current Implementation (Screenshot)
No response
@nichwall commented on GitHub (Dec 10, 2024):
I don't think human readable library URLs really matter. If you want to go to a specific library when first visiting the web client, you could use a bookmark.
You also generally shouldn't be recreating libraries, is there a specific reason you are doing that?
@ahobsonsayers commented on GitHub (Dec 11, 2024):
Completely understand if you don't feel human readable urls matter! I am not suggesting that all people will see the use of this - however I personally do feel it would be a great enhancement/feature, and I'd be surprised if I am completely on my own with this wanting this.
I also recognise this will be seen as a low priority feature to be implemented compared to others out there - im ok with this! That being said, if I were to do the work and add this myself, I would like to gauge how confident I could be that the feature would be merged.
I mainly don't want to put in the time if my changes end up being rejected by maintainers due to their belief that it does not matter - as is their right regardless of my preference.
Hope that makes sense!
@pwinnski commented on GitHub (Dec 16, 2024):
I'm nobody, but my two cents are:
The library uuid is defined in the database as a UUID type (authors, collections, libraries, libraryFolders, libraryItems, playbackSessions, playlists, and series tables) so changing that might have unexpected and wide-ranging impacts on db storage and performance. That said, I don't believe SQLite does hashing based on character distribution, so that advantage of UUID types doesn't apply here.
I also wonder what allowing an arbitrary string would mean for API calls. Presumably a library id would need to limited to a certain set of characters, and it has never included a space before, for example.
Still, given the wide and deep nature of the proposed change as well as the limited exposure or benefit accruing to the web client only, I wonder about alternatives. You've mentioned two benefits, and I wonder if the first might be better handled via URL rewriting.
URL rewriting would let you type in something like http://myserver.net/library/MySparklyBooks without requiring the heavy list of re-architecting database, api, server, and client. If you're not already using reverse proxy that allows for URL rewriting, even a TinyURL custom alias might do the trick at least for the initial-loading case.
You didn't answer nichwall's question about re-creating libraries, which you shouldn't really need to do. But I guess I would add that if you are worried about that, the library ID isn't even remotely the biggest issue you have: each item in the library will also have a new ID unless. you re-use the original database, in which case the library ID will also be unchanged.