Enable creation of same-named pages within a space

2017-Jun-13: Hello friend! You probably stumbled upon this issue after trying to create two pages with the same name in a Confluence space and the system complained. Bummer, right? It's okay, breathe. We've all been there. We've moved on.

Way way back in 2004, the Confluence wiki I setup under my desk was being adopted by thousands of people at Cisco, so I heard this frustration a lot. I created this issue to suggest an alternative, and lots of folks chimed in with ideas. 

Atlassian is a great company that does listen, and in Nov 2011 Sherif Mansour, the Confluence Product Mgr chimed in to put this issue to rest. (see below)

It's time to let it go.  

-Tim Colson

Hi everyone,

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 (-CONF-2814-)

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.

Cheers,
Sherif Mansour
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... )