Some web-based systems provide short internal (object) IDs one can use to link to / reference this object.
Ticket systems like JIRA are an example (each issue has a static ID, even if it’s type is changed or it’s reassigned to different projects or components), some online forum systems, and similar.
Concerning XWiki, there also was a discussion about this some years ago:
Does anyone know if such an extension exists meanwhile? From my point of view, it could be a convenient feature to have relatively short links to articles which are easy to share by e.g. mail and which stay valid even if the page in question is moved to a different location within the wiki…
Hi. No it doesn’t exist. This is why renames are complex in xwiki (it requires refactoring all the places using the page being renamed). Ideally it would probably be better to have an internal id and URL aliases for this id. That would make renames a breeze.
Now it would be a big change to implement and I’m sure there are negative effect of such a design vs what we have now (like performances).
@GOhrner For example, how would you create a link to another wiki page? Using the unique id would be quite inconvenient. So you’d need to use a clean reference which is what we have in XWiki. So if a page had an id, it would also need to have some reference and some URLs to access it. How do you make the reference stable?
Actually, I was more just thinking about an alternative way to access articles which could then be used to ceate links from the outside into the Wiki, keeping the current URLs and way of linking as “standard”. (The article could provide a “Create external link” or something in its “…”-menu.)
(That’s also what I think the mailing list post I referenced was about, though I admit I didn’t read the whole related thread there.)
However, those links could then also be used by the Wiki itself, of course - I’d assume that in the WYSIWYG editor, this would only be a presentation issue (the link editor should basically still look like today, but then probably generate the ID based link).
In the Wiki text editor, it would be more inconvenient, maybe here some approach could be used to use / store all links ID based internally, and perform some pre- and postprocessing of the article before editing and after saving, which replaces the ID based links by URL based links just for the edit session. Not sure how to deal with the WYSIWYG editor’s “source view” - maybe a pre-/postprocessing would then be neccessary in genral, which on the other hand would mean that the WYSIWYG link editor would not need any extensions or special-case behaviour.
Also, what to do with links to articles which have not been created yet - which today is one way to create new pages?
Not sure if it would be worth it. Those are no trivial changes, and those issues would have to be solved first. No sure if it would be much of an improvement compared to today… You’d make renames easier, but would then lose “explanatory” page URLs and add additional complications for editing, probably even wiki syntax specific.
For my point of view instead it would be much more helful to get rid of the “/xwiki/bin/view” boilerplate fragments in every page URL by default. This would already make links shorter and better readable.
AFAIK it’s already configurable if the “view” is being displayed, and there are instructions in your wiki how to work around the “/xwiki” part, but it’s all manual work and partially comes with drawbacks…
