-
Suggestion
-
Resolution: Fixed
-
None
-
37
-
2
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Hi everyone,
We're happy to share that we're working on a more intuitive URL format for pages and blog posts that includes the space key, pageId and page title. Going forward, page URLs will look like this: https://confluence.example.com/spaces/SPACEKEY/pages/pageId/Page+Title.
The pageId is used to retrieve the page or blog post, and the page title serves only to let users easily recognise pages. This means that links won't break when a page is renamed - they simply redirect to the updated URL.
References to URLs in the previous format like bookmarks will continue to work and also redirect the user. Even better, the new URL format also adds support for page titles that contain non-latin or special characters.
This change will be released soon. Please look out for it in the Confluence Release Notes, and continue to watch this ticket for further updates.
Kind regards,
Jacqueline Bietz
Product Manager
Confluence Data Center
Summary
URLs should be based on pageID instead of pageTitle
By default, a confluence URL contains the space and page title.
eg: http://confluence.mydomain.org:8090/display/KEY/Page+Title+Goes+Here
When the page is renamed or moved to another location, the URL changes.
This behaviour is not ideal / wanted.
Actual Behaviour
When a task is created, or somebody is mentioned, an e-mail notification is sent.
When a page title or location changes afterward, the e-mail link is broken.
The same goes of course for bookmarks.
This is frustrating for people as in a lot of cases, pages are being renamed / moved frequently.
Expected Behaviour
Confluence supports URLs based on the fixed page ID, which would overcome the above issue.
eg; http://confluence.mydomain.org:8090/pages/viewpage.action?pageId=12345
(if a page title contains non-ascii character, the URL is automatically based on pageID).
However, I cannot find a way to setup pageID urls by default.
For manual copy/paste sharing, we promote the "Link to this page" feature.
Unfortunately, most mail references to confluence are generated by the system.
What strikes me is that at the bottom of a generated mail, you have the links "view page", "comment" and "like".
"View page" and "comment" use to the standard link. However "like" uses the pageID link.
- is duplicated by
-
- Closed
- is related to
-
- Closed
- relates to
-
- Closed
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
[CONFSERVER-45898] URLs should be based on pageID instead of pageTitle
Hi 2149d3e47b04
Thanks for letting us know! To get help with troubleshooting this, please contact Atlassian Support, or alternatively post on Atlassian Community where you can get answers and support.
By the way, something similar was reported and it was isolated to Comala Document Control not being compatible with Confluence 9.1 yet, so you could either disable the plugin (if installed) or try reproducing it in safe mode with all third party plugins disabled.
Thanks,
Jacqueline Bietz
Product Manager, Confluence Data Center
a2879c3b3278 Hello, after updating from 9.0.2 to version 9.1.0, we stopped opening links in the old format (https://confluence.site.com/pages/viewpage.action?pageId=37357037) - when you click on such a link it says “Page Not Found", when opened through the other two types of links, everything opens.
A fix for this issue is available in Confluence Data Center 9.1.0.
Upgrade now or check out the Release Notes to see what other issues are resolved.
Very happy this is finally being fixed. I couldn't believe that a wiki could have this fundemental flaw of renaming a page would break all links to that page.
Hi everyone,
We're happy to share that we're working on a more intuitive URL format for pages and blog posts that includes the space key, pageId and page title. Going forward, page URLs will look like this: https://confluence.example.com/spaces/SPACEKEY/pages/pageId/Page+Title.
The pageId is used to retrieve the page or blog post, and the page title serves only to let users easily recognise pages. This means that links won't break when a page is renamed - they simply redirect to the updated URL.
References to URLs in the previous format like bookmarks will continue to work and also redirect the user. Even better, the new URL format also adds support for page titles that contain non-latin or special characters.
This change will be released soon. Please look out for it in the Confluence Release Notes, and continue to watch this ticket for further updates.
Kind regards,
Jacqueline Bietz
Product Manager
Confluence Data Center
It is sad to see that, this problem is still not solved. I am happy that I left using confluence.
We link pages from Jira Service Management to Confluence (and vice versa). And of course, a non-pageID URL will break once the page is renamed. Please remove that Titel URL Stuff and just use PageID!
Hi! I'd like to bring our use case too. We're migrating currently markdown projects to Confluence Server. One of the issues we face is indeed - page title logic. Unfortunately the current logic mapping the page title to a slug is too simple. What if we have one space, and we create some child pages per product. Teams maintain their pages and subpages independently. In our projects we used to have similar docs structure per product: Introduction, Usage, Troubleshooting and etc.
It means that the current design with titles like this is not possible:
Product A
- Introduction
- Usage
- Troubleshooting
Product B
- Introduction
- Usage
- Troubleshooting
Because if they live in same space - it will be not possible to create two table with same titles.
What if we allow to introduce also not only pageIds - which are result of internal server sequence but instead we give the users to provide their own unique page keys. Like for example using pattern like gitlab-<project_id>file<filepath> we can recreate the pagetree using those ids without taking care of actual page titles.
For readability purpose, this would be interesting to have, by default, a mix e.g.:
viewpage.action/InformationalCurrentPageTitleNotUsedToResolvePage?pageId=<number>
where InformationalCurrentPageTitleNotUsedToResolvePage would serve only as an hint to reader and only the pageId would be used to retrieve the content
This way, even if the page name change, it wouldn't end in a 404
The fix is a bad idea, there are so many ways this format can be misimplemented… A bare page ID would make more sense. (Links with it actually worked, they just required additional steps to obtain).