Page IDs for indexing
complete
James Byrne
Show the page's ID # on the navbar somewhere.
These are already displayed on the "Pages" admin panel, would be nice to have them be displayed on the page and be searchable like some enterprise wikis. (Also maybe navigable via URL in place of the "chosen" URL e.g.: wiki.test.io/en/28 instead of wiki.test.io/en/random-stuff)
Thomas Pozzo di Borgo
Thanks a lot Nicolas! Perfect, we can now link pages without having fear if later we change the path.
Nicolas Giard
complete
Added in 2.1.
Use
/i/123
to automatically be redirected to the correct path, only if you have read permissions. Otherwise you get Unauthorized and are not redirected (to avoid path leaking).Thomas Pozzo di Borgo
Hello,
We are in the same need.
(for tracking, I opened an issue for new feature on GitHub on https://github.com/Requarks/wiki/issues/1369 , sorry i didn't know it should be posted here).
Linking page in any wiki can lead to tiedous task if hard path is used and the targeting page gets its path changed. It involves knowing all pages were this page is called and change on each page the path.
Actually there is no tools to detect global dead internal link (a summary of all page having dead links), so we cannot correct them after renaming a page. The pageLinks table in database cannot be of great help because it don't have the source page information.
Parsing with LIKE request the page table can be a way... but very technical.
Proposition of redirection:
One way, the easiest one, would be to allow direct access page by ID.
So we can use internal link with a markdown like pageid/9. This will give:
It will be just a redirection a the path of page id 9. So no permissions to check as it will be handled on the redirection target page which will be the full path as usual.
So this is just a redirection to put in place.
(another way, could be to retrieve the path of the page id during rendering, but this will be as a little more code than just put redirection in place, but will be more proper)
It will really make life easier on big wiki using internal linking! Really.
Changing path is a lot more frequent than deleting a page/changing it's id, so I think it is valuable.
Proposition of global dead link detector: (later, redirection will mitigate its need)
In parrallel of the redirection feature, but can be done in a second time, in the adminsitration area in the page tools, a global internal dead link will be really really welcome. So we can easily check all internal linking is OK, and know whcih page we must change after deleting a page for instance.
I hope all of this make sense.
Actually we are using internal link and changing path (for better structure) is always a risky task as we can easily miss the page using the old links.
I know there is a dead link detection in place (which display the link in red), but it is not very helful if we need to go manually on each pages. I think it is just to show to the end-user that the link don't work and it is its work to report it... Here purpose of this issue is to be proactive and having the tools to make proper internal linking.
Thanks a lot, ... and i forgot your wiki is awesome ; )
Nicolas Giard
The IDs are meant for internal use only. The locale + path is the correct public identifier of a page.
What's your use case for having IDs on the page / URL?
James Byrne
Nicolas Giard: Easier hotlinking for internal articles in a CRM and a way to be organized while still being unorganized (not forcing a bunch of people to adhere to a URL structure.) I'm thinking of it sort of like how a lot of CRMs use ticket #'s to identify issues in spite of the titles.
In reality its so we don't end up with a bunch of internal articles like wiki.test.io/en/why-is-this-so-long-for-no-reason-whatsoever
Not a critical feature but something nice nonetheless.
Fushihara
Nicolas Giard:
You want to create an article, edit it to some extent, and then rename it to a better name.
There is no guarantee that you will always come up with the best title when writing an article.
If the URL is composed of titles, the URL string may be long.
In the case of markdown, text in long URLs is an obstacle to editing.