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. 

What a disgrace, it's very clear Atlassian needs a change of Product Management, this should be prioritized above every other feature.  Unbelievable that you are willing to take on this many years of technical debt that would have been avoided if had of been fixed back when it was raised.  

Seems like there is one duplicate of this still alive, which we can vote on: https://jira.atlassian.com/browse/CONFCLOUD-45279

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.

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 ...

This is needed, guys. There might be technical difficulties but you should figure out a way to do this. This is really annoying.

Worst issue in confluence

really annoying!!

annoying!

I do not understand how changing this would be a lot of work. Sure, you'd have to update lots of references throughout your code, but given that Confluence supports using pageids instead of page names already, it should be doable. Confluence uses the pageid whenever the page's name contains a character not deemed suitable for the URL. This happens a lot in our Wiki because of the German letters ä, ö and ü. Every reference pointing to these pages works just fine without using their name as an identifier.

WTF???? This is a necessity for any way to store documents within a hierarchy. Wikipedia has chosen to make a purely flat document space so they can get away with unique article names, but when you introduce a hierarchy, having to use paths that look like TweedleDee / TweedleDee Communications Board / TweedleDee Communications Protocol / TweedleDee Communications Protocol Meeting Minutes is a royal pain.

LOL ... just lol and shaking my head. Come on Attlassian make us love you as you always say you love us as soon an new release is announced! "You play an important role in making Confluence better." Yes, and we pay for it, so please find a solution.

Scroll Versions is a expensive workaround but not a solution. It brings other problems with it ... e.g. no more page move between spaces. But Atlassian won't kill an associate's feature....

Very disappointing indeed.

@Lars, thanks for that, i'm in the same boat, that plugin is too expensive to be added..... it should be core product.

I find it interesting that a third party has found a way to address this issue, yet it's in the too hard basket for Atlassian.
Please look into this again!! Buy the code from the addon supplier!!! Something!!!!

This is driving me nuts as well.. The currently best workaround for this might be to throw money at https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-versions and use the trick at https://www.k15t.com/display/VSN/How+to+use+only+the+Permalinks+Feature+of+Scroll+Versions. "Hey boss, I know I just asked for a lot of money for this Confluence-thingy, but can I get a couple of hundred more? ... Why you ask? hmm... Well, you see, I need a plugin to support a basic hierarchy of pages...".

Whats even more confusing is that the default confluence page-tree look, really hints towards that this is already how it works...

We continue to struggle because of the issues others have raised and the limitation makes organization and reuse Extremely difficult (e.g. lots of includes/excerpts instead of using individual pages; very, very long pages that defeats the purpose of quick navigation). We run into similar issue when creating documents that have the same structure: Overview, Pricing, Deliverables, Configuration, etc. Seems a core design flaw that should be resolved and provide the lead time necessary for plugin developers (it seems that stating all plugins would break is an exaggeration...confluence ones, maybe...but, some have also switched to using fully qualified names because of similar issues). With the inability for the normal user to easily find pages, increasing the number of spaces is not a good solution (remember, you took away the ability to easily search by labels...you require special syntax that the common user doesn't remember/know). So, having single knowledgebase spaces that are large are needed to minimize frustration and maintain usage/adoption.

How about reconsideration?

Extremely disappointing response from Atlassian - basically amounts to "We made a bad design decision and now it's too hard for us to fix it." Can we get this issue re-examined? If you guys had actually been working on a solution for the past decade, odds are this change would have been implemented long ago.

This is disappointing.

What are the development statuses of the items listed by Atlassian in 2011?

• 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

Wow. This is a ridiculous design flaw. I'm trying to document my infrastructure and got stuck when creating pages/subpages for each server. They would include same-named sections for each server (i.e. Hardware Specifications or Local Groups, or Services, etc). This should be a BASIC CONSIDERATION when developing a Wiki. My only solution will be to cram all of the information for each server or device into a single page. Sort of defeats the purpose of using this nice wiki system for organization.

Sigh.

We are looking for a similar solution. We have to create standalone product docs, but want to reuse many of the common features across the guides. For example - Authentication Requirements, Profile Management, Patient Search, etc. Therefore, we want to name the pages the same so that they can be pulled in as chapters where they belong in the separate guides.

We utilize the custom export to create these guides - thus, to use, they have to be in the right hierarchical order.

Each page should still have a unique reference (ie tiny links) and you can browse to a page to pull it in so that you know you are selecting the correct once.

Have more and more spaces isn't the answer when you want to create a knowledgebase of all client facing documentation or support documentation. And,you want to generate documents that include one or more products pulled together (I cannot use the space export to pull pages together across spaces to generate one toc/pdf)

Austin put a perfect example! I also use Confluence for storing marketing documentation, and need a universal substructure for subpages within a single branch. Thats what I CAN'T do due to this weird system limitation and I have to use some naming hacks that do not fit my initial purpose.

I guess with such amount of customers feedback with real cases Atlassian should have focused on the problem.

I am baffled by this... I want to use a space to house customer documentation.... something like:

Parent Container -> Customer A - Contracts
Parent Container -> Customer B - Contracts

Right now there is no way to do this and I am so confused as to why this is? This seems to me more to do with poor design than anything else. I am so confused by this response. This items has lots of traction and lots of customers asking for it. If your solution has a logical problem that prevents the use case that seems very common in a CMS type environment then you need to adapt and solve the problem by adjusting the tool - not by telling the customers it is excessively difficult or that it does not make sense. That approach is not well received by the user community that has real problems they are trying to solve. I cannot take the lay group of users I am trying to encourage to use this and present them with this as a solution knowing I will have no good answer when they ask this question.

Question... can anyone give me good alternatives to confluence? Lets change this to a conversation around what other options we have in the market so I can see how others handle this very complex problem.... sound reasonable? It is obvious that Atlassian will not remedy the situation so we need to talk about remedies ourselves.My guess is there may even be sites with import tools to bring Confluence data into a new home.

Thanks

I'd much prefer Atlassian get off their high horse and implement what many of their customers have been asking for for years. MANY people use Confluence for documentation and want the native feature to have multiple pages of the same name in the same space.

The VERY EASY workaround would be to change the stupid URL structure to use a UID. I don't care what the URL says. It could be http://mysite/display/SPACE/PAGE which does nothing for me. I don't care that it says SPACE and PAGE. It could just as easily be http://mysite/display/UIDSTRING

A VAST majority of users are not hard-typing URLs into their browser, so having this as a UID is just fine. It's what EVERY major site uses...you don't go to YouTube and type in youtube.com/watch?v=cat-fighting-a-monkey for good reason. There are too many similar videos.

If it impacts search, it's only because search was designed poorly, and a simple workaround should suffice, e.g. showing full breadcrumb trail on mouseover or many other solutions.

Agree with everyone else. Terrible design flaw.

I agree with Artem. Although so far we are living with this major limitation it's not cool at all that it exists. @Benjamin, one does not merely search based on page names, there is actual page content and labels. If one is simply searching based on page name, then the full power of Confluence is not being leveraged. The requirement that page names be unique really was a major design flaw and will continue to limit the adoption of Confluence, sadly.

There's a SO answer that fits for me: http://stackoverflow.com/a/21430695/1469503. It basically says that you should give every page a meaningful name. Having 100 pages named Installation might break the power of the confluence search function.

The rejection to fix this issue certainly breaks the practice of structuring documentation: in many cases it is needed to have pages with the same titles within different branches of the space
+1 vote to reopen this issue.

If Atlassian is unwilling to make this change because it would break so many additional add-ons and macros, then maybe they should consider forking Confluence into a new product with a focus of structured technical documentation. That seems like what many of the people asking for this feature are using it for. Add support for Docbook and/or DITA... Could be pretty awesome.

Sadly, a deal breaker for me. I can see the issue only becoming more and more of a problem the more we use it. A shame as I really wanted to like it too. It has a lot of good features. Back to Sharepoint then. Sigh.

Adding my +1 since this is closed and I cannot vote.

When first using Confluence, I was a bit disappointed with this issue. As I'm trying to use it more and more, it's becoming an even bigger issue. Apparently not enough foresight was put into how the system designed and the limitation when Confluence was first being built I suppose. Almost like having a regular link and a tiny link, there really should only be tiny links in case a page name is changed. I'm sure this has been said before but their ought to be some sort of unique id/hash for each page and that's all that matters. The page title/name,contents, locations, etc should not matter one bit. Very sad to see this won't be fixed. Having dozens or more spaces is not practical at all.

We found two solutions / hacks for the problem:

1) Purchase https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-versions
2) Install https://marketplace.atlassian.com/plugins/com.nurago.confluence.plugins.treecopy and use a zero-width whitespace (U-200B, ​) as page title prefix

Hope that helps anyone.

That's it. I'm done with Atlassian. This is just retarded. First all the bugs and troubles with the setup and customization, but this is totally the final note.

The ability to have nested Spaces would alleviate some of the pain around this.

On the other hand a Wiki is about searching things. And if I search for "technical documentation" and get 100 hits with the same title, I have an even bigger problem, too.

What might fit better would be to get a wizard as soon as you want to create a new site with the same name. This will let you create a disambiguation page like wikipedia uses.

And as a sidenote, Wikipedia uses unique pagenames, too, and it works. Confluence is more like a Wiki and not like my filesystem.

The problem I might face will be that if we should roll this out as a company wiki, we'd have to explain one department that they can't add their "technical documentation" page to their project, because there might be another project set up by a differnt department who used that title. I wouldn't want to work in a service desk there ^^.

Stephan, It' really hard for me to understand the logic behind your reasoning. Following the same idea there should be no 2 files on your computer with the same name, but they does! And your PC works well, right?
In real world, when you send a web-link to somebody you copy the entire address, right? So why the same cannot happens for Confluence.
Anyway, you're worry about technical details concerning ambiguous link, this is not you're job. We're client!

There are dozens of different way to solve the problem. Ok, let's speak about my little website: when you add a new page you have to specify the name (even duplicated) and an "alias" (a unique name). The alias (usually generated by the system, but you can modify it if you want) is used for referencing page, but only the name is displayed.

So, believe me, the problem could be easily solved, and a commercial product (not so much cheap) should offer a solution. If not, it would be like living in a world where only one person could use the name "Smith"...

Previously, I was in favour of creating same-named pages within a space. But meanwhile I changed my mind and would rather leave it as-is.

I think it would make many things in Confluence more complicated and difficult to understand. For example when inserting a link to a page. Consider this space structure:

Home
+-- JIRA
    +-- Installation Guide
        +-- Introduction
+-- Confluence
    +-- Installation Guide
        +-- Introduction
+-- FishEye
    +-- Installation Guide
        +-- Introduction

How can I tell which one to choose if there are several with the same name? Every dialog or popup would have to show the page's full ancestry. The same is true for search results, links to attachments etc. I think the current rule "Every page in a space has a unique name." is easier to understand for novice users.

This is massively disappointing to read through.
To read that an issue, with so many votes, is not being fixed because it is difficult to fix has honestly nearly made me fall of my chair.

I have had at least 5 senior staff come to me looking for an explanation on why they are hitting this limitation, each one doesn't believe me when I explain it to them. The usual response is "are you serious, but that is so basic and fundamental. How does anyone use this?".

This isn't down to difficulty, it's down to "(and costly)". Here was me thinking that was a paid for service.
This is basic functionality and it needs to be in the system, regardless of difficulty and cost. If things didn't get done because they are difficult and costly then we would still be living in caves.

Maybe the Product roadmap should be less about making minimal benefit fixes to the toolbar and more about working on the core functionality.

I'm really disappointed by hearing that Confluence will never allow to have two pages with the same name in a space... (when they are located in different positions of the hierarchy)
From my point of view this is an incredible lack of the product itself.
I mean, in everybody in a company (I suppose) try to build up regular structures, patterns or whatever and replicate them to save time (and money). I think this a natural (human) behaviour. Splitting the same regular "pattern of document" across multiple spaces is a complete no-sense for me.

I would like to have the freedom in choosing what is more suitable for me, not for the tool.

We will continue to use Confluence but, I repeat, I'm really disappointed.

Greetings.

I'm a very recent adopter of Confluence, and I find this annoying too. A document tree with several sections all having an introduction subpage just looks silly as 'Introduction 01', 'Introduction 02', ...

I've noticed that when I import a MSWord doc with sections, Confluence disambiguates same-title pages by appending a number. Why not do this as pages are added, either uploading or those entered by hand, only map the copy number to an invisible non-printing subset of characters? Either that or maybe cage the added number in an HTML element that is styled to not display. That way the legacy Confluence constraint would be respected and the human readability factor would improve.

And, while on the subject of URLs, although somewhat off-topic, it may be worth the "Share" pop-up having something that shows links / code that could be pasted in to emails / other systems, much like Skitch uses, for example:

(the html small/medium/large aren't really relevant in context of wiki page link – those are just specific to skitch as it's screenshot/image sharing site)

I've not used WP much, but that sounds pretty much like what I was thinking. But also with option to customise page URL even if the page title is unique, as sometimes Confluence auto-generates ugly URLs.

It's particularly important to have meaningful URL when posting links via email or in forums. People want some idea as to what the page is about before clicking the link. viewpage.action or something filled with %'s is offputting to many users, particularly "non-tech but slightly aware of what phishing is but not enough to work out if something is phishing or not" users.

Guy – By "PageURL" do you mean something that is akin to the WordPress "slug"? So for a page with the name "Meetings", the slug/pageURL would be empty. When somebody tried to add another "Meetings" page, the slug field would magically appear and the user would need to choose something (presumably other than "meetings")?

Or did I miss the point?

Coincidentally, I published a blog post about a "slug" field a couple weeks ago internally. I like the idea since I do not like either the pageID=432432 or tinyURL links because they lack semantic value. And I don't like the page-name links because they lack permanence. A slug of "wiki_upgrade_meetings" for a page named "Meetings" would, it seems, fix most of my users original complaints.

Aside, if all pages were given slugs upon upgrade, and default slugs upon new page creation, then uniqueness could be guaranteed with a DB index, rather than the current dodgy (and broken) practice of testing the page title against the Search Index which results in duplicate named pages!

Cheers,
-Tim
P.S. If I did miss the point, my apologies.
P.P.S. I agree about the instant search - awesome feature, but with thousands of spaces, it's all too easy to bring up dozens of the same page name.

Grr, can't edit comments. Typo above, should have said:

This solution would still require hundreds of UI updates everywhere a page is selected, searched for or displayed.

I don't believe that's true any more, not since Confluence 4 where all the link stuff was centralised to display link suggestions. Surely the vast majority of link additions are now done through a more centralised point in the code due to re-use of that link suggest thing?

(pics of link suggest think in my comment above)

Or... Atlassian could just add a PageURL property to page objects and give users the option of editing it when they add/edit pages. It's not rocket science.

Since this issue was first raised, there has been a MASSIVE overhaul in the way links are added to Confluence due to the new editor in Confluence 4. I think this issue should be revisited with a fresh set of eyes as what was decidedly non-trivial pre-Confluence 4 might now actually be quite straightforward to do.

In Atlassian's note at the top of this issue, the following reasons were given for not fixing this issue:

* 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/)

Not as much, or as regular, confusion & frustration as having to tell end users, over and over again, that they can't use the page title that they want because it relates to the URL (which will often look ugly as hell - eg. viewpage.action or %'s) and that they have to add cruft to their page title to make it unique.

* 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"

Don't these already lead to you getting a viewpage.action URL? Even putting brackets in page titles lead to ugly viewpage.action URLs (or at least they do on my OnDemand instance).

This solution would still require hundreds of UI updates everywhere a page is selected, searched for or displayed.

So it's a much smaller change than the Confluence 4 editor overhaul then, and you managed that.

(When do you display the full qualified title? When to do you just display the post-slash title? etc...)

When there are multiple pages with the same title of course!

Oh, and while your in there, you can fix this issue where there are pages with the same title in different spaces:

Maybe by using same approach as in quick search results:

If there is more than one page with the same title in a specific space then also include the parent page title in that grey text, in this format: <space title> / <parent page>

I'll pre-emptively tackle some other possible rebuttals:

What about areas of Confluence that still use wiki markup, like page templates

They shouldn't be using wiki markup, for exmaple, not being able to use Confluence 4.2 "page layouts" in a page template because the page template is still using wiki markup is just weird.

And, in any case, a URL can still be pasted in and it's my understanding that Confluence 4.1+ will autoconvert it in to a proper link, just like when user copies page URL and pastes it in to editor window already.

It will break loads of third party plugins

Every single release of Confluence since 2005 has broken loads of third party plugins due to API and UI changes. We're kinda used to it by now.

In summary:

Add a PageURL property to page CEOs.

Have it collapsed by default on the add/edit screens.

If page title is not unique, or would result in ugly URL, auto-expand URL panel:

• User responsible for providing an acceptable unique URL
• Page can't be saved until the URL is acceptable

Update link auto-suggest so that it a) shows space that the page is in and b) additionally shows parent page if there are multiple pages of same name in the same space.

There would prolly be a few bits of the XML-RPC API that would need tweaking, and plugin devs would need to be given advance warning that they will need to check their plugins for compatibility.