mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-15 03:09:38 +03:00
[Feature Request]: Migrate Self Referential Links on Copy #2636
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 @Arcynic49 on GitHub (Feb 3, 2022).
Originally assigned to: @ssddanbrown on GitHub.
Describe the feature you'd like
I document a software product for work, and initially skipped over considering migrating to BookStack (from Confluence) because of the lack of copy functionality. One workflow I needed to be able to use was copying the documentation for one version into a new version, and then changing the sections that were updated in the new version. With the recent release of copy book/chapter functionality, I've started getting ready to use BookStack (it is very well made) but I've noticed that the copy functionality isn't working exactly how I hoped.
While the copy does in fact create a new fully copy of everything, any self-referential links do not get updated in the new copy. It would be desirable for these links to point to the new copy rather than the original. By way of example (meant to be illustrative, not how I'm structuring stuff currently):
If you perform a copy of Book- Software Version 1.0 to version 2.0, the section below shows the results (actual links in bold, desired in italics):
This example shows it for a book, but the logic conceptually applies to chapter copies as well as page copies (if there happen to be links on a page referring to itself). Anything linked via permalink should naturally be exempt from these rules.
Describe the benefits this feature would bring to BookStack users
Ideally this would enable faster updates of content following a copy operation, as you would not need to manually update links that the copy has that are meant to refer to itself-as-a-copy and not the original-prior-to-copy. Since this logic only applies to copy operations and not moves, it is thus hopefully more contained and useful.
Additional context
No response
@weiyuemin commented on GitHub (May 27, 2022):
I have exactly the same condition, hope this feature..
@bourdaisj commented on GitHub (Jun 11, 2022):
Hi, I started taking a look at this
@bourdaisj commented on GitHub (Jun 14, 2022):
I stumbled across this TinyMCE feature the other day.
maybe when the link is added we could figure out it is referencing some sibling items, insert the link as "relative" (?) and use the
url_converterto generate the correct link based on the item parent. Don't know if I'm being clear on this, apologies if I'm not.I think I prefer just rewriting the links on the backend when we perform the item copy but I thought it would be worth mentioning this solution as well. @ssddanbrown wdyt?
@ssddanbrown commented on GitHub (Jun 15, 2022):
@Julesdevops I would prefer that any logic for this is kept to the back-end, and that we don't rely on any TinyMCE features. There are three potential editors to consider, TinyMCE, Markdown Editor and API (Markdown or HTML input). I don't want to add TinyMCE logic that we'd need to emulate elsewhere. I generally look to keep user content as "dumb" and "magic-free" as possible to keep it somewhat portable; that extends to relative links. Using full absolute links gives us firm patterns to relatively confidently match on, while being functional outside of their original intended context.
@bourdaisj commented on GitHub (Jun 15, 2022):
@ssddanbrown agree on this, thanks for the feedback
@ssddanbrown commented on GitHub (Nov 29, 2025):
This has now been added within #5917 to be part of the next feature release.
Thanks @Arcynic49 for the original request, and thanks @bourdaisj for taking an earlier attempt at this.