298
Moving a page should update links
planned
Activity Feed
Sort by
Jim Bridger
Creating a page that had links to it also does not update the pages that link to it (they stay red until you rerender that page)
James Miller
Yes, every wiki I've ever used does this. Keep a variable that has a list of "backlink" items that is updated on each edit / page creation, and use that to quickly update all the other backlinks. AND then in the admin section where the current rebuild everything / re-render everything buttons are, put a fix backlinks button to do a slow crawl over entire site.
Kartal Armoni
really interested
Markus Jochum
I can also only point out how important this feature for any serious wiki/knowledgebase/documentation project within wiki.js is.
It is vital that internal links never ever break, just because somebody renamed or moved a page. The link structure between pages is a fundamental part of a wiki and should support the dynamic & ever changing nature of an active wiki. Moving and reorganizing content and pages should always give the users the possibility to automatically update all internal links within the wiki.
I also love the way that for example the personal knowledge base software from obsidian.md works in this regard.
No matter how often you rearrange, reorganize your pages/notes there, it always instantly updates all internal links and the associations/links between your notes are never lost/broken.
Regarding external incoming links from external sources linking into wiki.js, something like permalinks using never changing ids could be a solution for that kind of scenario, but for wiki internal links, i think auto-updated name based links are the way to go
Marc Hodgins
Take a look at the way wordpress handles this. Rather than trying to parse and update page content with links, simply maintain a redirect table with old URLs pointing to the new page location. Each page keeps a history of its previous locations, and an HTTP redirect is done if it is accessed via an old path.
Nicolas Giard
Marc Hodgins: The problem is that users would still expect links on the page to point to the new one directly (e.g. when you mouseover or copy the link). It's a good idea but doesn't fully address the problem.
jensb
Marc Hodgins: This feature is overdue, but your suggestion doesn't work if the user wants to reuse previously used links to new pages.
A clean way of doing this would be an option "[x] Update all links to this page" when moving/renaming wiki page locations. This may require a global search & replace action in all pages, or just an update of an "page_id <-> page_url" table, depending on the Wiki.js structure.
But I'm also eagerly waiting for a feature like this.
Marc Hodgins
Nicolas Giard and jensb: Ok, I agree, rewriting internal links in the page content to the new path would be nice. But even with that feature you still need a default behavior to maintain a redirect table for old paths. This is necessary to avoid breaking inbound links from external sites, links in old emails, etc.
If the user wants to intentionally re-use a path for a new page, then consider providing the ability to manually delete from the "previous paths" redirect table on each page settings, and/or, check for conflicts when creating a new page and delete the redirect.
jensb
Marc Hodgins: As long as this means that I can create stable wiki-internal links between pages
and
shuffle pages around (rename, move, restructure) after creating and interlinking them, I'm good. I don't care so much about external links.I like the way Atlassian Confluence (commercial wiki) does this: You can link by using the page name, e.g. /wiki/WhateverTitle, but since this breaks when renaming pages, you can also link by using the page ID which never changes, e.g. /wiki/page?id=XXXX-YYYY-ZZZZ-1234. Internal links (autocreated by typing a page name in [...]) will
show
the page title by default but automatically contain
the ID based link looked up on creation. The wiki also offers a "Copy link" button on each page which copies the ID based URL for external use. Also, the page namespace is flat, so shuffling around stuff in the site TOC around won't rename any pages.Maybe some of this can be applied to Wiki.js as well.
N
Nicolas Gerard
Marc Hodgins: I think you mean Nicolas Giard :-)
Nicolas Giard
planned
It was working at some point but now it's broken...
Hein Thet Khin Zaw
Yes. we need this! 1+
Yusuf Gungor
+1
Eve Vinclair
👍
Peter Uithoven
This might be a duplicate of https://requarks.canny.io/wiki/p/persistent-links
Josh Cox
Peter Uithoven: It definitely is. I don't know about other, but I'm not personally willing to go through the extra effort to lookup ids and use them directly. I create links to all sorts of pages that don't exist yet so that creating those pages later is just a bit quicker; if I were to use page IDs I wouldn't have this convenience. I suppose if it becomes a problem I'll switch to an alternative to WikiJS.
T
Thomas Nilefalk
Josh Cox: Well. I don't think it is a duplicate of that feature request, as that seems to have been interpreted by Nicolas Giard as being able to use ID:s in links, considering his "Completed" marking on it. A suboptimal solution since they are hard to get at, not natural, and requires you to do manual steps when inserting links in an article as opposed to using the "insert link" button.
I interpret this feature request as "when I move a page all links to it should be updated accordingly", which I think is the correct way to handle it. As Nicolas Giard also mentioned, "title based URLs will stay the default" so I think the solution should be to use title based URLs and update the internal links in articles.
T
Torbjörn Maaherra
Thomas Nilefalk: I interpret the feature request in the same way, and it is definitely something that is needed.
Right now we are doing fine internally in our company, and with growing content it will become harder and harder to maintain.
P
Peter Uithoven
Peter Uithoven: I now realize it's not really an duplicate. This request is more about updating links when urls change, while the persistent-links request is more about creating links in such a way they can't break.
I think both would be great features.
Load More
→