-
Suggestion
-
Resolution: Won't Fix
-
None
-
None
-
3
-
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
Problem Overview
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.
Update 2017-Jun-13: Tim added a quick note to let folks who want this feature know they should "let it go."
History
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.
Proposal
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".
Additional Considerations
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>}
Advantages
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
Summary:
Enabling non-unique page names through the use of "namespaces" would improve space organization, breadcrumb navigation, and PDF/HTML exports of page hierarchies.
Cheers,
Timo
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... )
- blocks
-
- Closed
- is duplicated by
-
CONFSERVER-41219 Unable to create subpages with the same name in a space
-
- Closed
-
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
-
- Gathering Interest
-
- Not Being Considered
- relates to
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- was cloned as
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
[CONFSERVER-2524] Enable creation of same-named pages within a space
I ended up postfixing everything with what's above it in the page tree (and renaming everything when I move it around ...).
This is becoming quite annoying as our wiki grows. If we had been aware of this limitation when choosing our wiki system-to-be we would likely have chosen another solution...
I guess a workaround to reduce the problems a bit is to use more spaces instead of top-level "documents"...
There are addons which do this , not sure if available for the cloud. A basic flaw. Hard to recommend Confluence for folks who are maintaining a library of documents as opposed to a Wiki.
Hello,
I am about to move 1000~ pages from a space to another, which results into an impossible operation, given your constraint.
Let's put aside that you didn't manage to find a solution for this problem in 18 years (not even a rewrite happened so far?)
Sometimes you may also try to solve the problem in a different way.
For example, what about providing an helper to generate a unique name while moving a page? maybe a prefix, maybe a random number? Come on guys, It took me 5 minutes to generate some ideas!! With the money that we pay for your tools I would expect a bit of reaction, possibly within the next 20 years??
From both a system and application design perspective, the choice to make the title a key in this way is completely wild, and not to mention re-inventing a solved problem - URL keys and slugs have been separate to titles on nearly all systems for managing pages and documents for decades and for a good reason.
The more I use confluence the more I'm certain Atlassian musn't be using their own products internally. The solution proposed of separating by space simply doesn't make sense, and anyone who's used Atlassian knows how drudging it is to flip and change between and juggle dozens of spaces.
I fail to see how the proposed solution works for documentation that needs repeated structures underneath certain pages.
This is a perfect case study for why you do not make your unique identifiers a natural key. Always make a surrogate key.
Other non-printable characters may be used as well, but not all of them. E.g. [PAD] and its neighbours do work, while, say, [NUL] or [BEL] don't.
I am doing this dark trick of adding as much characters ASCII 255 as needed to have an unique name. This pseudo-space character is also not rendered in usual html browers.
You can also enter this character from its ASCI code in most editors pressing the key <ALT> + 255 , (when the confluence editor don't allow me create this character y am using copy/paste of this char from other editor)
Interesting workaround indeed, but only for some specific situations. If you have for example a set of pages each describing a feature, and for each of these pages you want sub-pages e.g. "Requirements", "Design" and "Test" or whatever, you'd need a different number of hair spaces for each set of those sub-pages. Doesn't scale very well.
interesting workaround @lingrlongr - do you see any issues with this approach? Does the search still find all your pages?
This has frustrated me for years. Upon checking to see if this was ever remediated, I found this page. I was disappointed in the response, but the previous comment gave me an idea. Here's the result:
(update: can't upload image, but give it a whirl!)
The 2nd Child is the same name (obviously), but has a "hair space" unicode character \u200a in front of it. I used to Python to create it:
>>> print('\u200aChild')
Child
I used this one-liner to generate the 2nd name and copy it:
$ echo Child | python3.8 -c "import sys; data=sys.stdin.read(); print(f'\u200a{data}', end='')" | pbcopy
The HTML will show the title as  Child but the space will not be very noticeable when rendered.
It is really frustrating this limitation to not allow use the same title for two pages of the same space!!!
(e.g. 'Introduction' for tho chapters of a documentation book)
Is it possible at least do some trick to define a 'hidden' part of the title, to aparently show a repeated name?
e.g.
<hidden>1</hidden>Introduction
and
<hidden>2</hidden>Introduction
This is quite weird logic. You assign Page IDs to make the pages unique. And top of that, you want the titles to be unique as well. Actually, we are struggling to organize huge number of pages without the ability to have duplicate page names. There are 3rd parties who seem to be fixing this but you don't want to fix. We don't want to purchase a 3rd plugin for a feature as basic as having the ability to create pages with the same name.
This could actually be quite hilarious. Until the difficulties of adding in hundreds of application documents arose. Looks like Confluence might be a thing of the past - literally.
Please implement this very basic feature as the document manager...
Don't excuse and escape
Your customers leave from confluence and start using notion now, it is really shame
I've also got to agree with the above posters, especially Matt Flaherty and UHD SV-BW.
The company I work for has two compelling events to consider - firstly, a redesign of our organisational documentation structure to become less siloed and more service-oriented (and keep all scope, design, engineering, delivery and operational information for a given service in a single hierarchy), and secondly Atlassian's move to cloud/SaaS-only. As an organisation with a strict on-premise requirement due to the data regulations we work within, this puts us in a very difficult position with regards continuing as an Atlassian customer.
Between that and the "we'll wait for the marketplace to fix it so we can get a cut of their charges" as a method of fixing problems within the product itself, the attitude towards "features" like this, along with the SaaS-only approach, it would appear that Atlassian is doing it's level best to remove itself from our IT landscape.
If voting were unlocked, I'd gladly vote for this. The way things are now is completetely unintuitive.
If there really are companies out there who need pagenames unique, you can add an instance-wide toggle, like the one for assigneeless issues in Jira.
Reopen this and get this fixed Atlassian!!! It's a shame, there are so many open issues of broken or non-existent basic functionality in your products. 16 years since this has been opened and nothing from your side at all?!? That's so ridiculous.
Observing your longterm issues for some years, you are always playing the same game of "gathering interest", leave it open for some years and suddenly just close it again with a "won't fix" with long chatty excuses why this is not an issue at all, it's not your technical debt, nobody would be using it, bla bla bla. Instead, you are always appending your usual marketing look-what-we-are-focusing-on-instead-and-what-always-same-sounding-scalability-bla-bla-things-and-cloud-nag-nag.
Every year so ever you are raising your prices by 100...500 %, now you started to break up with your majority of on-prem users.... We really need to get away from your products and the ever-increasing financial drain it imposes on our budgets. You are obviously not able to fix your very own products' design flaws, you are continuing to ignore the most basic customer requirements, and clearly your new cloud-first-and-nobody-knows-when-DC-will-be-your-next-onprem-victim strategy shows, that you cannot be trusted as a long-term on-premise software vendor anymore.
I am just so disappointed!!!
The original poster wants us to let this go. Well, maybe you're happy to let it go. For me, I can only shake my head and wonder why I can't specify both a url title and a display title. It seems like that would be easy. That would then allow me to keep the URLs unique and have the tree browser show the same link text under various nodes that have similar descendant layouts, like documentation for different versions of the same software application. That is consistent and concise. This design decision is dumb. Yeah, I guess I could use spaces or non-printing characters but really.
What a roller coaster ride this issue has been. Literally went to see if I could turn on a configuration to have the hierarchy be a part of the permalink to fix this duplicate title issue. Turns out Atlassian has decided this is a non-issue. So, Tim, I'm letting it go. And by it I mean Confluence. What a disaster, this company.
Notion.so has this feature and lots more. I just switched away from Jira and couldn't be happier. It's also a natural Confluence replacement and cheaper than both.
Yet again, Atlassian is demonstrating its ignorance of user needs. This is how companies fail.
It is really ridiculous how Atlassian handled this!
Ancient MS-DOS 1.0 did not support a hierarchical file system. Then MS-DOS 2.0 came out, introducing directories. Now suppose that Microsoft would mandate, even with MS-DOS 2.0, that all file names in a drive would need to be unique...! I.e. you could not have 2 files with the same name, even though they were in different folders! Because it would confuse users when searching for a file by name. And they would maintain that even when Windows 95 came out! Which is the same time period that we are facing this issue now already.
This is what Confluence does by design and refuses to fix. I even doubt that product managers read the complaints with enough care. Many examples were given of completely sane use cases, but the only suggestion they give is to use more spaces. What if you want to document 100's of features, each with sub-pages for Requirements, Test Design, Schedule...
Yeah, that's actually what we've moved to over the years as we grew at my main job. We use System Center to manage most of it there and then Jira/Insight to pull it into tickets. Works great for an enterprise environment.
I handle a couple of small businesses on the side (a holdover from my self-employment days from years ago), who are much to small for all of that sort of asset tracking and monitoring infrastructure. In that case, I document things manually and Confluence works great for that. Other than these little oddities that I have to work around. It's not enough to find another tool – I love Confluence otherwise – but these pain points are often in my face.
However, even at my main job, we still have other things we document, particularly procedural documentation, where there is a lot of structural repetition in the document layouts. Gets a bit annoying there.
Hi Daniel,
i completely understand and totally agree that this is a flaw. A big flaw.
Btw. we use Jira to document assets in our infrastructure, which has the side effect of history/log and defined processes for on- and offboarding assets or moving them, or whatever aso.
We only display generated lists in Confluence.
Documentation is done by defining the infrastructure in Ansible/Terraform where applicable.
But i know, tis doesn't help here.
Smaller spaces makes 0 sense for certain types of documentation. One difficult use case is technical documentation of infrastructure. The document structure repeats for each like device or system (i.e. server, switch). For instance, each server will have similar properties and procedures (i.e. Description or Installation) that will repeat for each instance. It makes no sense for me to create a space for each server. Instead, we're stuck prefacing those similar sections with an arbitrary number of other descriptive element, which then creates other problems such as how it's presented when exporting the space. Otherwise, you just have to create a massive page for each server, losing the benefits of breaking them into sections. This is a basic thing.
I totally agree on that it should be able to have pages with the same name in a space - this should be fixed.
But meanwhile, you should give spaces at least a try. Use smaller spaces instead of big meta spaces. Consider moving branches of your site tree into their own space. Spaces gives you also other benefits: f.e. smaller units of pages and contributors, better organizing, easier permission management, aso.
Same here. Project documents have all the same structure: this makes Confluence useless to store project documentation (unless we create a mile-long single page of course for every product and project we do).
pre- and post- fixes are a workaround I would expect from a 16-yo self-thought indie developer product.
Having same concerns for Confluence. Don't know when this feature will release. Please suggest some alternative tools.
Personally I think it's ugly that I have to put suffixes like _2, _3, _4 to pages with the same name. I guess it makes it less searchable too.
Don't let your competitors disrupt you on a feature like this.
People must not need it that bad if they have been using it for 15 years without this feature. I personally switched to another product....
This request is from 2005, today (2020) we, the users still needing this feature; it is too bad that atlassian doesn't reconsidered again.
Need this feature! There is literally no way to automate common page creation without some unique user input or scripting to access the pageid or a unique counter. Just use the whole url... I couldn't care less about a short "pretty" url when it removes useful functionality.
The worse part is that the solution is painfully simple! Just add page id into the URL and problem solved!
Use <conf-url>/<pageid>/<pagename> and problem solved.
I stumbled on this problem when trying to create Customer Directory for my company.
It's ridiculous to think that Page name must be unique because Confluence is developed on "wiki" concept. However, it still promotes content to be organized in "tree-like" structure which both two are totally conflicting concepts. Think of XML schema that each node name has to be unique....
I understand that Confluence might be too big to fix now. But I still insist that Atlassian should fix this no matter what. Perhaps implement something like "Apparent Name" of Page title, etc..
Jesus Christ, I cannot believe that such a basic functionality is still not implemented. You can paint it in any way you like it but this is a basic failure that should have been fixed a long time ago. Is this 2020 or 1994?
Mike, because there are different perspectives on that. Our space has 25k+ pages and we are perfectly fine with it as it is.
Just switch to another tool if this one does not satisfy your reqs. No need for blaming at all.
I don't see why people use this product, it is perfectly sensible to need\want pages with the same name. They could have even changed it years ago when it was easy but the teams arrogance prevailed.
Just another, of many, reason to convince management just how poor this product is and why we should quit using it.
Right, it's mostly about the navigation.
Without having doubled page-titles there you end up with horrible long names, like:
"Navigation Point 1: Sub-Navi-Point 3: Sub-Sub-Navi 2: A name nearly 50% of pages have (like settings)"
THAT'S HORRIBLE!
Who had that idea to make a page name unique?!
Why not allow the label of the page in the navigation to be customized? I don't actually think the "Page Name" necessarily needs to draw the line of war on this topic. What people are really hoping for is a way to represent the navigation on the left as something structured and repeatable. If I could just have that, I would have no problem making each "Page Name" unique. I just want the damn label in the nav to be the same. Make it a new property or something..."nav display label" and don't change anything else ¯_(ツ)_/¯
That functionality has never been part of the system. As such there are conventions within the product that would be almost impossible to change. Especially, when you think about all the third party apps that have been built that expect Confluence to only have one page per space with a specific title. As an example think of any macro that lets you select a page in the macro parameters. As you type the page name and get suggestions and multiple hits for the same space pop up how would you know which is the right page to select? As it is right now if you have two pages with the same name you simply have to look for the right space, but take that away and now you could have twenty pages in the same space with the same name ... how would you know which to pick. I get how much people want this, but honestly I don't think it would be possible to make that kind of change even if it were just Atlassian involved. Now add hundreds of app developers and it really is not a very realistic idea.
Hi Alexander,
Stop with the strawman. The question is not "is ther an app I can buy that will solve my problem", the question is why is this feature not supported out of the box.
Hi Joel,
checkout this app: https://marketplace.atlassian.com/apps/1219390/duplicate-page-titles-same-page-titles?hosting=server&tab=overview It allows you what you have requested.
+1
I love this product but I hate that absolutely every page in a space has to have a unique title.
The below scenario should definitely be possible but is not:
- Software 1
- Meeting Minutes
- ...
- Requirements
- ...
- Releases
- ...
- Meeting Minutes
- Software 2
- Meeting Minutes
- ...
- Requirements
- ...
- Releases
- ...
- Meeting Minutes
A page name should be just another attribute. It really is that simple.
Pages already have unique ids that can be used in the URL, in fact, we only share those URLs anyway, in order to prevent links breaking when the title changes.
So why is it so difficult to use uniqueIds in URLs, and append the page name if you really want to?
Something along the lines of amazon URLs:
https://www.amazon.de/Atlassian-Confluence-5-Essentials-English-ebook/dp/B00DAZUTBW/
https://www.amazon.de/dp/B00DAZUTBW/
Those two links are taking you to the same page.
Right now the Confluence URLs is https://<confluence>/display/<space>/<page-name>
And the share URL is https://<confluence>/x/<page-id>
Why not use https://<confluence>/display/<space>/<page-id>/<page-name> for the display URL and solve everyones problems?
Is this really that hard to do?
Requiring all pages to have globally unique names, rather than just names unique within their parent scope, makes a lot of other confluence features useless or hard to maintain. For example, consider the childtabs feature. If each space contains many teams and each team contains many pages, then space/team/page must have a title "Team: Page" or some similar prefixing scheme. This then means that every single tab listed by childtabs starts with the name "Team: ". Yes, you can configure childtabs to drop a hardcoded number of prefix characters, but that's very brittle. Everyone who creates a page needs to remember to prefix the page title in exactly the same way, or it appears with a weirdly truncated name in the childtabs display.
Atlassian's position on this seems to indicate a lack of understanding of some really basic computer science fundamentals (name resolution within hierarchical scopes). More importantly, Atlassian is obviously ignoring their customers. I came here via this community question (https://community.atlassian.com/t5/Confluence-questions/Not-able-to-create-a-page-with-the-same-title-as-another-page/qaq-p/332910?tempId=eyJvaWRjX2NvbnNlbnRfbGFuZ3VhZ2VfdmVyc2lvbiI6IjEuMCIsIm9pZGNfY29uc2VudF9ncmFudGVkX2F0IjoxNTY5OTY3NjU4ODk2fQ%3D%3D) where the Atlassian position has literally 0 upvotes but user requests for the feature have several.
How would you feel about a file system not supporting hierarchies? "You just need to prefix your file-name".
Please reconsider.
btw, that's nice to add comment every 3-6 year because as more companies asking the same limitation.
I hope once Conlfuence team will provide built-in functionality like implementing 3 option: