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. 

https://en.wikipedia.org/wiki/Natural_key#Disadvantages

shame this is not a feature

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 &hairsp;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!!!

+1

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.

+1

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?!

855a84f8fb9c, great idea.

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
    • ...
• Software 2
  • Meeting Minutes
    • ...
  • Requirements
    • ...
  • Releases
    • ...

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.

Please consider reopening the issue!

I am just here to say that it is a bit lame to not do what the customers ask for. Please consider reopening the issue.

That said, I love the haiku!

This remains a design flaw and a usability issue.  As Confluence gets promoted to be a universal content tool not just used as a niche wiki and documentation tool for developers to paraphrase Pratima Arora, this will come up again and again. 

It's a first thing that came to my mind when I was reading the load of goo justification above, alongside with "we don't care about our technical debt". Truth is it's not a solution but just a workaround, and I guess given there are paid plugins that kind of do the same thing, they could have issues with it? I doubt nobody else thought of this before (I mean if they didn't then W-O-W).

Anyway, this whole thing is really disappointing. I understand the logic in the justification but I really don't like/agree with it. 

I like Adam's proposal of a display name property to a page. It'd be a solution I'd be satisfied with given this long-standing design flaw.

Adding a "display name" property of a page, to be used within the GUI rather than the unique page "name" property (which can still be used for links/plugins/etc), is a simple fix. I'd like to hear the reasoning from the engineering team as to why something like this isn't implemented. It truly is a shocking design flaw.

Hi 淡定,

please open a issue here: https://jira.veniture.net/servicedesk/customer/portal/2

We need some screenshots of the bug. Did you change the encoding of the system?

Hello Alexander,

     when use your add-on, the space page tilte and content get unreadable Chinese character. Can you help to fix it?

Hi,

we developed an add-on to solve this issue. We did not 100% resolve this problem with same name. The reason is that we did that and found out that confluence does not work like that. For example when you do a search you see only page title and the space. So if you search for a page title which is available multiple times you need a reference to the parent page. Therefore our add-on adds a special prefix which will be hidden in the most places.

You can check the solution here: https://marketplace.atlassian.com/apps/1219390/duplicate-page-titles-same-page-titles

The problem with individual spaces is that Jira Service Desk can only link to one Confluence space.

By default, Confluence sets up a "How-to articles" and a "Troubleshooting articles" page.
Both of these article types will cover the same system components, how are you supposed to keep this organized? at even 3 levels deep when the prefix includes the last 3 parent's names?

@Martin Salas, the "solution" is to create individual spaces for the two projects. This allows you two name the pages identically. This does work well for large projects, where using two different spaces improves navigation in general. However, Atlassian is unwilling to support a different use cases, where users would like to have lots of smaller projects in one single space. This is a common usecase in both my company and in many other companies too, but sadly this issue is one of many which Atlassian prefers to ignore.

Just ran into this today as a new user

Since this is a wont fix issue

how have the people here gotten creative with their page structures.

What I was trying to achieve

Project One > File List 1 (supporting docs)

Project Two > File List 2 (supporting docs)

in both cases above, I wanted to name a sub page supporting docs... How do you guys deal with this. Is there another way I should be looking at the IA for this? 

Just a comment to bring back this issue. 

Well, in this case we'll continue to prefix the title with the category path in each single page.

How bizarre!

In that case..

I want to remind Atlassian that this is still an issue for me. Just yesterday it made sense to me to have same name page within same space.

Useless comments spam 268 people, and they clearly don't help anything - Atlassian is not listening.

Yes you can't vote on it but you can watch it and comment on it. Each new comment on an issue is a broadcast to every watcher of the issue (especially including Atlassian people) so I believe has more outreach than a vote. Comments keep it fresh and hot.

There are already 200+ comments on the issue and as the club of unhappy users grow so does the number of comments.

What I don't like (aside from the fact that this issue has been consigned to Won't Fix-Land) is that because the issue is resolved, we can't even vote on it, so there's no way to quantitively express our collective anger to Atlassian staff.

Very poor performance of Product Manager in this case - just denying a feature request which would make lives of hundreds of users way easier justifying this by technical obstacles which could be overcome. And the worst thing is that Product Manager and the team doesn't offer any good alternative to overcome this and basically says to all it's users "just deal with it, it's not our problem"

Why, are you planning to remove it ??

I'll need to write a haiku for wiki markup next

Having a lot of troubles documenting my project because of this. Probably it will affect my choice for wiki in the future. 

2017-Jun-13: Hello friend! ... Bummer, right? It's okay, breathe. We've all been there. We've moved on.  ...It's time to let it go.  

• Tim Colson

Frustrating to see how a company turn its users into ridicule. 

+1

I am trying out confluence and this is the only blocking point for my team to adopt. This means I will run into problems transferring old work (word documents) into confluence because they all have introduction, conclusion, reference section unless I have separate spaces for each document (however, I do not believe this is the intention of how spaces are meant for). On the other hand, this doesn't allow me to export a page and it's child properly into a pdf directly because I'd need to remove the common namespace first. For example, the "Q&A Testing" namespace will appear in each of the headers in the pdf file; however, I want "introduction", and not "Q&A Testing Introduction" for the first header, and so on.

It's interesting to read about the history of this request and it's also very sad because without overcoming this bottleneck in a more automated fashion, we simply cannot adopt the tool. 

[Update] I am using Scroll Versions which can decouple permalink and the page name.

This is a needed feature, seems Atlassian do not realize how their tools are used in real life.

For example:

We have 1 space for a project. Suddenly it was split in 2 phases, so now I need to call every requirement with the phase in brackets, instead of just having 2 parent pages - Phase 1 and Phase 2.

Yes, part of requirement goes into Phase 1 and other part goes into Phase 2. Does not make sense to have different name for same requirement in different phases.

Very frustrating and the explanation not convincing at all....

Extremely bad engineering. Please implement this feature and address your customer's needs.

+1 to all the complaints.  It is frustrating to observe the can being kicked and the customer being ignored.

Fix this please!!!!

This issue seems closed - no one at Atlassian seems watching, you probably add your votes and comments on: CONFSERVER-45279

I have to use a kind of "preface" page for each of my documents that displays revision and approval history for auditing purposes. Each page has the same headings, so I created a template, only to find out that I have give each page I create with this template a new name. Kind of defeats the purpose of having a template, doesn't it? Many good solutions have been proposed here, none of them hard to implement. Perhaps Atlassian Development and Support teams live on Mars, and it takes 30 years for our messages/complaints to get to them so they can listen to paying users, and fix the problem?

This is so annoying, everytime you try to create some well structured content in your confluence wiki you get reminded of this issue!

I cannot understand why this won't be fixed, this is a major issue. Just add a display title, so you can create good organized content and not a hell of prefixed pages which is confusing for all readers.

Unbelievable that a software company refuses to resolve substantial mistakes for 12 years. Remember the 1990ies when we laughed about Microsoft...

Very good point Robert.

Per Atlassian support (via twitter), I respectfully ask that this be re-opened so we can at least vote on the issue. Otherwise it will never fit into your process.

EDIT: I can't do @mentions, but \tag Sherif Mansour. Apparently as PM this falls to you. 

I agree that this has to be fixed and corrected. I've read the inputs here and most of them are sound solutions to the problem. I really find it annoying that a page title/display name has to be unique in a space.

Is my understanding correct? This issue was created in 2005 and it's 2017, still no concrete permanent solution? Incredible.

Not able to use the same page name - It sucks.

The technical solution is clear, but it would cost too much money to fix it, because "breaking this assumption would require thousands of changes" as stated in the official reaction above. And then Atlassian must pay for it (modifying all plug-ins that others wrote).

So if you want to have this bug fixed: spread the word that Confluence is an annoying tool, convince some big Confluence customers to use a better tool instead. Because a company should gain more money (new (or keeping) customers) than loosing it (by fixing this)...

I agree with the others who have recently posted, especially given that Confluence is often spoken of as the leading wiki provider.

I can completely understand the technical reasons for why this has been rejected, if Confluence retains the notion that a page ID comprises of both the space and the title. I would agree that this is indeed a design flaw - it is almost always a good idea to introduce an internal ID that is hidden from the user, that can then be safely used within the system, and by plugins, macros, etc.

However, I do not see a reason why there couldn't be a workaround. A new field, perhaps, labelled 'Display Title', or 'Space Title', or otherwise, that defaults to the instance title (actual/current title), but allows users to safely rename so that within the page hierarchy, and the page title itself if could be changed to something more appropriate and succint?

This really needs to be fixed asap. This is severely impacting my ability to use this platform. I find it disheartening that the matter seems to have been closed, even though people are still commenting regularly about this obvious and significant design flaw.

To follow-up on my previous post and on what Jasper said. I would be quite happy with a solution like Scroll Versions. It is a real attempt to address an obvious issue.

I was asked to make a recommendation to my company of a good solution for documenting our software systems and business rules. I like Confluence but this issue is making it more difficult to choose this product and to convince other people to use it. When I talk to my colleagues about the product I find myself saying something like "Apart from some very annoying issues with naming the product is really very good!" Surely if someone who wants to go with your product but feels like he needs to apologize for this issue it is something that you need to re-address. 

Even if I was to agree with you that it is critical that you maintain the simple URL structure (which I am not convinced about), that is no reason for not offering some solution to this most obvious issue. 

I say all this not because I don't like your product but because I do, and it is clear to me that this issue is and will continue to be a big stumbling block for users.

At least, bring out a free add-on which allows duplicate page titles. If k15t (Scroll Versions) can, so should Atlassian. Nobody wants to pay the full price of Scroll Versions if you don't need all the other functionalities.

I thought Confluence was great until I encountered the problem myself and then found this issue. Hugely disappointing.

Please re-open and fix properly.

This limitation is a roadblock / hurdle for our organisation to fully migrating our process control and documentation systems in to a purely JIRA/Confluence environment.

+1 to jospeh

I have read your reasoning for closing out this issue and I can understand it. BUT it think it is crazy. Respectfully, I believe it is the type of reason that kills a good product. You talk about the difficulty in supporting add-ons. but when you have such a glaring issue (I encountered this issue within about 1 hr of trying out your product) people will not even get to the point when they will think about using add-ons before they will be frustrated. I also see that although you say that this can not be achieved without a huge effort that will set you back a significant time other company's have offered workable solutions bundled into their add-ons (such as https://www.k15t.com/software/scroll-versions). We would not need all that this add-on has to offer but it would seem that if they can offer this as a third party developer you should at least be able to offer the same.

Here is a link to what my Page Tree looks like, with all the unnecessary Dates and Project numbers required to stop conflicts between projects.

https://1drv.ms/i/s!AlbAIlvoZh4Ug_QyT4pGCPTuU7Z6iw

You may say, why not create a space for each project. But this is not feasible as there are many projects and they are usually relatively small.

Please do some serious reconsideration of this issue. There must be a better way then just to stick unnecessary text on to all the titles!!! Scroll Versions has demonstrated one viable solution.

Other than this issue, I am very impressed with Confluence!

Kind regards,

Joseph 

I've googled and found this issue and was really disappointed.
This decision spoils all good points of tree structure of the pages.
Please consider reopening this issue.

1. If this restriction is not resolved, please interpret slash in a page name as separator for directories and automatically build and display tree structure in the left pane as same as PukiWiki does.

Hi @smansour, as you can see this issue is causing a lot of grief, can this please be re-opened/investigated within Atlassian.

I don't think that anyone at Atlassian is still reading on this closed issue.

Just want to note here that it looks like this issue has resulted in us cancelling our plans to migrate our documentation to Confluence. Enforcing article titles to be globally unique by space is really just crazy. Even more so is using titles and filenames to store link references in the database, especially when every content item already has a perfectly usable globally unique ID. Honestly just completely baffled by the design here.

This comment really summarises the burden and impact this decision places upon users:
https://answers.atlassian.com/questions/213925/answers/14199837

Making end-users de-dupe titles by hand is just nuts - enter a title, "sorry, this title exists", add an obvious suffix, "sorry, this title exists", repeat ad nauseam. The drop-dead simple fix for URLs is to prepend/append the ID to the title, add redirects for previously existing URLs. Obviously the story for add-ons sucks - they must update to use IDs instead, but that's what major version bumps are for. The storage format would also need to be migrated so that all reference tags use IDs instead of titles, and the API would need minor updates. Obviously a non-trivial job, but not even particularly complex - throwing hands up and putting it in the too-hard basket is not a winning strategy.

Also met same issue during developing online doc with Confluence.
I am really disappointed to hear that the issue CANNOT be fixed!

Damn shame, becoming a deal breaker as our database grows larger and larger.

And BTW: Confluences uses already Page IDs!!! E.g. if you got german umlauts in the page title....

like ..... pages/viewpage.action?pageId=12060834

I'm still ROTFL ...