Deep links do not work after changing the permalink of the page or the layout - support a unique page ID suffix in the URL and a unique layout ID!

[AnRei123]

Bug description

Today, it is already state-the-art that you can do the following changes w/o compromising the functionality of a referenced deep link:

• Rename the topic (currently supported)
• Change the permalink of the page (currently NOT supported)
• Change the permalink of the template page (currently NOT supported!)
• Change the structure of the navigation (currently supported)

Deep links do not work anymore after changing the path information of a page!!!

Especially, in the beginning when you start creating pages and menus for your developers in the portal, you cannot ensure that the initial structure of the menus and the topic names can be kept for ever. And you can also not ensure that the current layout can still be used for a topic in future.
Currently, I phase the issue that the path information in the permalinks of the Pages and Layouts is outdated as I need to restructure the navigation and menus for the existing pages.
But with the current Paperbits approach it is NOT possible to reflect this change consistently in the permalink that is displayed in the URL for the user!!

Our developers need to be able to use the permalink as a deep link on their dev-internal wiki pages or for the API descriptions. But with the current approach, to ensure that a link is really permanently functioning, I cannot change the path information for a topic when I need to restructure a topic or to use a different template!!!

This is really a very poor and old-fashioned behavior and leads over time to very inconsistent path names or broken links!

Reproduction steps

1. Copy the URL of a portal page from the browser and add the URL as an hyperlink in the description of an API or API product or in an e-mail.
2. Click on the referenced hyperlink and check if the page is displayed. Test result: OK
3. Select a layout in the Layout list in the portal and change the permalink.
4. Select a page from the Pages list in the portal and correct the permalink according to the change of the permalink for the layout/template.
5. Click on the referenced hyperlink in the email or in the API description. Test result: FAILED

Expected behavior

Follow a similar approach as Microsoft Azure already does for Azure DevOps wiki pages. When a new topic is created, autogenerate a unique numerical Page ID that is always used as a URL suffix after the domain name of the portal.

Additionally allow adding an individual path suffix for each page after the autogenerated ID suffix that is displayed in addition in the URL.

Even if the individual page suffix is outdated in the referenced permalink, still display the right page content with the right layout is based on given unique page ID right after the domain name.

Even if a user is only entering the domain name with the page ID suffix, the right page with the right template shall be displayed.

Even for the Layouts, automatically generated unique layout IDs should be used to identify the right layout. On the Page properties in the editing mode of the portal, the right layout shall be selected via a pulldown list that shows the current display names of the layouts! But the unique layout ID should not be required to invoke the right page content with the right template assigned!

The new permalink convention for pages in the portal should then be the following:
https://<domain-name of the portal>/<unique page ID suffix, e.g. 12821>/<individual page path suffix>

This approach ensures that even after changing the individual page path suffix, a deep link referenced in an e-mail or in another wiki page or in the API description would still work - even after the structure, the underlaying layouts or the individual path information for pages has been changed.

It should be ensured that older pages that originally had been created without a unique Page ID still work after a redesign. Older permalinks without a unique page ID should be still supported and work 3 years after the roll-out of the redesign.

The unique Page ID should be displayed in the Page properties dialog in the editing mode of the portal.
Optionally, it should be possible, to manually assign an individual, unique Page ID to allow to merge different pages from different contributors at any time or to switch the permalink between different existing pages.

When autogenerating a new page ID, the portal shall verify that the new ID is unique.

Here an example of a link to a page in an Azure DevOps project:
https://dev.azure.com/<tenant-name>/<project-name>/_wiki/wikis/<wiki-name>/12821/<topic-name>

This request is very urgent and should be prioritized very high to avoid messing up further cross references between the portal pages and different environments and the inconsistency between the names of articles and the URL name. Please provide a solution within the next three months. This and the missing search engine, are for us missing vital enterprise features.

Especially, as there is still no full-text search available for all the provided API entries and pages within the API portal, with increasing the number of pages, it is very important that deep links are supported in a very robust and flexible way!

Is your portal managed or self-hosted?

Managed

Environment

• Operating system: Windows 10
• Browser: Chrome
• Version: latest

##Additional information
Not sure if the solution required in the here referenced ticket may also be relevant for a quick solution Feature Request - Add IDs to Page Controls

[mikebudzynski]

Thanks for opening the feature request. You may consider using URL shortening services to temporarily mitigate your problem.

[AnRei123]

Wish you a happy and healthy New Year! Could you give me some more details on how to utilize URL shortening services? I am not familiar with this approach and do not have any clue about it. Is it an APIM setting? Would it be a special portal, Azure or Web service? Does this also apply for the managed approach and why does this service would temporary mitigate the problem?