Aha! Knowledge - Must Support Proper Slug Architecture for Knowledge Base

What is the challenge?

• The current slug implementation for a notes-diven knowledge base does not live up to any meaningful standard definition of what slugs are for.

• Right now, slugs in aha! simply are "functionally irrelevant, but pretty parts of the url"

• The actual use case for slugs, however is to provide a better, more powerful, "speaking id system" for pages that is supposed to supersede the primitive page-id pattern

What is the impact?

• Right now, a url in an externally accessed Aha! KB can only be accessed via its page-id.

• That makes slugs functionally completely irrelevant.

• The impact is: extremely long winded url patterns with both hard and ugly page id requirements

• For example, right now it's not possible to clone a page tree to do extensive edits in the clone and then simply retire the old page tree to then enable the new one: That would break all external links to the old pages.

Describe your idea.

• Slugs in an Aha KB must provide a comprehensive, powerful, enhanced and alternative id-system to page ids. They must not just be pretty text components in any URL that are otherwise functionally irrelevant.

Here's the status quo for the pixi help pages:

The Status Quo - very unstable and extremely long-winded:

https://pixi.help.descartesservices.com/pixi-knowledge-base-de/benutzerhandbuch/pixi-mobile/pixi-mobile-einlagern-auslagern-umlagern~7543506976981997788

Even without page-id, it would still be far too long-winded:

https://pixi.help.descartesservices.com/pixi-knowledge-base-de/benutzerhandbuch/pixi-mobile/pixi-mobile-einlagern-auslagern-umlagern

This would be shorter, but still not ideal:

https://pixi.help.descartesservices.com/kb-de/pixi-mobile-einlagern-auslagern-umlagern

Ideally, we should have really been able to reuse and migrate to the exact same slug patterns that we had in the past when we started to use Aha! knowledge:

https://help.pixi.eu/pixi-mobile-einlagern-auslagern-umlagern

^ (Only) THIS would be a proper slug implementation, also providing a healthy migration path for any existing KB. So, Aha! should really provide a CSRF-safe hook mechanism for an external site to update "only the slug" of a defined endpoint and nothing but.