Wiki page names must be unique within a space. This makes organization painful if a space contains similar topics, e.g. "Meeting" pages for multiple teams or projects within a single space.
Update 2008-Jul-11: Tim updated this description to be more succinct, readable and incorporate some ideas from the three and a half years of comments below.
In December 2004, Tim Colson noted many user questions with respect to creating pages with the same name under different "parents". Tim brought the topic to the Atlassian mailing list where it was suggested that a Jira case would allow people to vote on the improvement if it was important to them relative to other issues.
Please vote for this improvement if you think it would be beneficial.
NOTE: This proposal is at a high level. Obviously this problem does not have a simple solution and there are many use cases that must be carefully considered before implementing such a significant change.
Request: Confluence should allow pages with the same name in a space if they have different "parent" pages.
For example, two "Status Report" pages could exist if they are for separate project teams:
ANC:Q&A Testing Team/Status Report
ANC:Development Team/Status Report
Where ANC is the space key, Q&A Testing Team and Development Team are pages and BOTH have a child page, "Status Report".
Searches for "Status Report" would return both results, and would need to also display the hierarchy context so the user could pick the page.
Links would need a fully qualified name if there is more than one "Status Report" page, perhaps using "/" as a divider, in similar fashion to traditional website links.
[Q&A Testing Team/Status Report]
New and existing links to the non-qualified name (i.e. [Status Report]) would trigger one of two actions:
1) if saving a page, Confluence could validate and ask the user to select the correct alternative
2) if clicking an existing link that has become ambiguous - the user could be prompted, "This page name is not unique, please select the correct link from these options: <list>}
With this feature page names can be re-used in the hierarchy and navigation will be improved because there will no longer be a need for duplication of the parent name which creates long and redundant "breadcrumbs" and page titles, e.q.:
Current unique name restriction
Dashboard > Q&A Testing Team > Q&A Testing Team Status Report
Dashboard > Development Team > Development Team Status Report
Improved version, no unique restriction
Dashboard > Q&A Testing Team > Status Report
Dashboard > Development Team > Status Report
Enabling non-unique page names through the use of "namespaces" would improve space organization, breadcrumb navigation, and PDF/HTML exports of page hierarchies.
Firstly, thanks for your helpful feedback on this ticket. On behalf of the Confluence team please accept our apologies for allowing this issue to remain open for some time without any Atlassian feedback.
This issue has been open for quite some time because we would really like to address this issue in Confluence. However, after looking at it in depth and discussing it internally and with external plugin developers, we've realised we won't be able to make this change to the product.
Why have we taken so long to respond to this?
With the upcoming release of Confluence 4.0 and a move to a unified editing experience, we wanted to make sure that we have exhausted all possible options to resolve this issue. As we discovered, it is much more difficult to implement than we would have hoped for with significant consequences touching every plugin, macro and every link that is in Confluence.
When Confluence was designed initially, it shipped with the idea of "spaces" as a container for wiki pages related to one area of your organisation. The name "space" was an intentional allusion to "namespace", the word used by other early wiki software to indicate a group of pages where each has a unique name. This didn't seem like an unreasonable restriction; you can have as many spaces as you like, and it allows the user interface to remain simple - you can find or identify a page in a particular space simply by its title.
Since then, a huge amount of development has taken place in and on Confluence with the assumption that a space key and a page title uniquely identify a page in the wiki. As Guy mentioned below, breaking this assumption would require thousands of changes to areas as wide ranging as macro parameters, APIs used by plugins, remote APIs and page list UIs. Not only would a change like this impact the large majority of plugins create and every plugin developer, but we believe this change would also have an unreasonably large impact on our end users. Every non-trivial plugin that ran in Confluence would be broken by a change to the fundamental way that you retrieve pages. Every piece of content would have to be updated for the new macro parameters, requiring an extremely long upgrade process. Many operations that require the simple selection of a page by name would have to be redesigned to account for the fact that multiple pages in a space can share the name, complicating the use of the product for all our users.
We know that many of you are asking "but what about the suggestions on this issue"? We've spent some time looking at all of them (and several other options). The most realistic solution would have been the "page hierarchy in the page name" option. However, this also has several significant implications:
- It causes major confusion between parent/child hierarchies and namespaces: (Page called Foo/Bar with parent called Foo, move it to a different parent but it's still called Foo/)
- Pages that might otherwise naturally have a slash in their title: (Create a page called "Website A/B Testing". Becomes page called "B Testing" in namespace "Website
- This solution would still require hundreds of UI updates everywhere a page is selected, searched for or displayed. (When do you display the full qualified title? When to do you just display the post-slash title? etc...)
In general, implementing any of the the options would come with a very large cost to the product roadmap as well. All work on other aspects of the product would have to stop for a long time in order to implement this, blocking our ability to continue to deliver improvements and other feature requests you have raised.
If we're not going to implement this feature, what will we do instead?
We still believe that organising large amounts of content is one of the main features of Confluence and we need to improve this experience. To that end, we're planning to work in the following areas that help with this problem:
- scaling to larger numbers of spaces.
- managing large number of spaces more easily (link to issue)
- improvements to the page tree to better support organising content in large spaces
- introducing the ability to create template page hierarchies (
Thank you again for your long-standing interest and feedback on this issue. I can assure everyone that this was not a decision we took lightly. We're confident that the improvements we have planned will address these issues in the best way for all our customers.
Confluence Product Manager
smansour at atlassian dot com
After nearly seven years waiting for a reply, it comes to an end.
There is a tradition amongst the Old Guard IT guys at Cisco to write a haiku when something moves on....
Same Named Pages
Lively you were from O' four.
Seven years on...gone.
(I'll need to write a haiku for wiki markup next... )