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

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

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.

The spaces where deleted in my comment above as well Atlassian really doesn´t like spaces .....

It should be 1 space in the first on, 2 in the second and 5 in the last one.

And since, atlassian "eat" all the spaces the result is that all pages apears to be namned "- Project 1".Even if they are in the same space.

//Fred

G´day Mates,

A workaround to this disturbing issue is to name the pages "- Project 1" and the next page to "- Project 1" and the fifth one to "- Project 1"

The spaces between "-" and "P" will not be visible (except from the url in the browser) and since you all use tiny link for linking it is really not a problem.

Chears
Fred

laszlo.papp Sorry to say, I don't really have anything else to add other than we've had a our engineers and product architect look at this problem for quite some time and it is a very difficult (and costly) problem to solve.

Hi Sherif, hi Atlassian Team,

thanks for your reply on this issue - even if not communicating on such an important issue for 7 years(!!!) is kind of a (very bad) joke!

I understand the difficulties you described concerning some possible ways of implementation for this. However I would have been happy to read about what the difficulties with the "name + display name" solution would have been - which seems to be the simplest possible way to deal with this problem to me.
That would mean, that the page name (and also its handling in plugins and links) could remain as it is now, but the user had the option to define a "display name" for the page too, which doesn't have to be unique in a Space but can be used when displaying the page and the navigation on the left hand side.

To me, it doesn't seem to be hard at all.

Could you please describe here, what I overlook?

Thanks for your answer in advance - hopefully not in 5 years.

All the best,

Laszlo Papp

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

It is clear that Atlassian isn't rushing the solution for this problem.
No one is looking for a quick fix here.
Non-Atlassians have already invested a lot of their own time suggesting solutions and working round this problem.
The lack of feedback from Atlassian isn't helping either.

Prior to Confluence 4, it would have been cumbersome to link to pages if Confluence had supported same-named pages within a space. You'd have to type in as many page ancestor titles as necessary in order to get a unique path to the correct page.

However, Confluence 4 now has a useful auto-complete link feature in the editor, so from a UI perspective it should be now much more feasible to handle same named pages - users will see a list of pages, and if there is more than one page with same title in a space then the page ancestry can be shown in order to clarify where the pages are, allowing the user to select the desired page. And, once the desired page is chosen, the hyperlink added to the page can be based on CEO ID (as we no longer need to worry about wiki notation under the hood) so this solves some technical problems.

But I would imagine there are still issues that make same named pages a non-trivial task...

First, there are still lots of integrations out there where customers pump wiki markup in to spaces from external systems, for example automatically generated reports or exports of documentation, etc. As those would be using the usual wiki markup for page titles, what should Confluence do if a non-unique page title appears in one of the links? Should it just guess? My assumption is that a new "disambiguation" feature would need adding so that such links would display a list of possible pages and allow the user to choose the right one.

Second, there is the issue of URLs, which are based on page title. When a second (or third, etc.) page is added with the same title, what should it's URL be? There are various approaches to dealing with this scenario, such as adding the CEO ID to the end of the URL or adding some other number to the URL. Alternatively the URL could be based on page ancestry - at least enough to give a unique path to the page (but this could lead to very long URLs).

Third, there are lots of plugins and other customisations that are built on the assumption that page names within a space are unique. While the server-side component of plugins could probably be quickly updated to use a new API that can handle multiple pages of the same name, the same cannot be said for user interface elements of the plugins. To update the user interface of plugins will in some cases be quite problematic and time consuming. As many customers worldwide rely on plugins (for example, Adaptavist license over 15,000 plugins per month so LOTS of customers are using plugins!) this could have quite severe impacts on the ecosystem.

So, I think Confluence 4 certainly opens the door to this feature now being implemented from the end-user perspective of adding links in the new editor (and that deals with probably the biggest barrier to implementing this feature), but there are still a number of obvious technical challenges to think about.

I, for one, am extremely glad that Atlassian haven't implemented this feature yet. If they'd done it pre-Confluence 4, the end user experience of adding links would have been dreadful. And if they do suddenly add it, without those other technical considerations being dealt with on a widespread basis (eg. all plugins updated to handle it) then the ecosystem would be plunged in to chaos.

I think, despite humanities compelling desire to "just f***ing do it", some ideas are better formed and implemented if their prerequisites are dealt with first. Remember: "The chief source of problems is solutions." – Eric Sevareid (Broadcaster)

I do look forward to a solution to this problem, but preferably one that's not rushed and doesn't cause a whole bunch more (and worse) problems.

I agree. If you have requests open for 6 years, alarm bells should be ringing.

Really? This has been outstanding for how many years and received so many votes ahead of other issues and there isn't any resolution or even any recent Atlassian response?

I concur with these folks. This is absolutely a limitation that needs to be overcome. And soon. Come on guys!

This is nice:
Support for Office 2010: Satisfying over 60 of your votes
(http://blogs.atlassian.com/confluence/2011/08/confluence-4-wiki-beta-available.html)

What about our 348 votes for on issue?

Sehr geehrter Absender,

leider bin ich zur Zeit nicht im Büro und kann Ihre Nachricht momentan
nicht bearbeiten. Ab dem 05.09.2011 bin ich wieder im Büro zu erreichen.
Bitte wenden Sie sich in dringenden Fällen an:

Peter Haunert
Tel.: 030-5900903-37
Email: peter.haunert@pinuts.de

Diese Mail wird nicht weitergeleitet.

Dear sender,

I'm currently not in the office and unable to answer your message.
I'll be back in the office from 2011/09/05. For urgent matters, please contact:

Peter Haunert
Tel.: 030-5900903-37
Email: peter.haunert@pinuts.de

This mail will not be forwarded.

Mit freundlichen Grüßen
With kind regards

Stephan Giesen

We are rolling out confluence in our company.
Every time we let a new group of people use confluence, it takes about half a day before someone hits this limitation.

Come on Atlassian!!! Give us some feedback!!!!

Since nothing seems to happen with this I looked for alternatives and found Foswiki (www.foswiki.org). Very easy, very feature rich, very beautiful. Never looked back. Maybe this could be a solution for others.

Cheers,
Willi

Sehr geehrter Absender,

leider bin ich zur Zeit nicht im Büro und kann Ihre Nachricht momentan
nicht bearbeiten. Ab dem 29.08.2011 bin ich wieder im Büro zu erreichen.
Bitte wenden Sie sich in dringenden Fällen an:

Peter Haunert
Tel.: 030-5900903-37
Email: peter.haunert@pinuts.de

Diese Mail wird nicht weitergeleitet.

Dear sender,

I'm currently not in the office and unable to answer your message.
I'll be back in the office from 2011/08/29. For urgent matters, please contact:

Peter Haunert
Tel.: 030-5900903-37
Email: peter.haunert@pinuts.de

This mail will not be forwarded.

Mit freundlichen Grüßen
With kind regards

Stephan Giesen

I want to suggest a solution to this issue.

Instead of storing the page name, we could store the full path as page name.
The path separator character '/' is not allowed in page names and could be used for this.
The name shown when displaying/editing the page at the top should be the 'Display Title' (the last part of the path).

So a page named Child under a page named Parent would have a name: "Parent/Child".
A link to this child would look like this [Parent/Child]. It would also be displayed as such 'Parent/Child'.

I don't think this will require a lot of changes. Also the API and such could remain virtually unchanged.
Probably a small fix is needed when storing the files, to have the separator character encoded in some way.

Storing page names like this could be a space level option (e.g. 'Hierarchical page names').

It would be handy if this came with a link-to-child feature.
For example, links starting with a slash refer to a child page.
e.g. [/Child] on page Parent equals [Parent/Child].
Implementing this shouldn't be such a hard effort either.
Renaming a page should then go up the page hierarchy to change these child references as well.

I hope this could help getting this issue fixed.
As I said some weeks ago, some feedback from Atlassian on this issue would be greatly appreciated.

Wkr,

Tom

Sehr geehrter Absender,

leider bin ich zur Zeit nicht im Büro und kann Ihre Nachricht momentan
nicht bearbeiten. Ab dem 29.08.2011 bin ich wieder im Büro zu erreichen.
Bitte wenden Sie sich in dringenden Fällen an:

Jan-Philip Riehle
Tel.: 030-5900903-32
Email: jan-philip.riehle@pinuts.de

Diese Mail wird nicht weitergeleitet.

Dear sender,

I'm currently not in the office and unable to answer your message.
I'll be back in the office from 2011/08/29. For urgent matters, please contact:

Jan-Philip Riehle
Tel.: +49 30-5900903-32
Email: jan-philip.riehle@pinuts.de

This mail will not be forwarded.

Mit freundlichen Grüßen
With kind regards

Tilman Issing

http://xkcd.com/937/
makes me think of this issue

We have a 500 users license.
If only I had 500 votes...

...but that wouldn't mater? would it?

Could someone with access to Confluence 4.0-m36 EAP update the 'Affects Version/s' list, if applicable.

Can we have a comment from Atlassian? After 6 years, what are your plans with this top-3 voted issue?

Here is a bit of ironic humor – check out CONF-14151 which I found back in Jan 2011. It shows that it is possible to create same named pages within a space, but that process is the result of a bug, not a feature.

Number 3 actually...

This is a big issue for our company as well and we are quite disappointet about the way it's handled here. No information about any plans to fix this issue. No assignee. Just nothing at all. Even it's probably the highest rated issue around.

It is clear that this is a difficult issue to solve, but it definitely isn't unsolvable.
When Atlassian looks at their confluence product backlog, it must be clear that this is a high business value feature!

We can all vote on this issue, but nothing seems to happen...
Atlassian ought to either plan the fix or close the issue.

I think it's simply too hard....and Atlassian has been loathe to admit this, unless you read between the lines.
It's an issue which has been there since day one. That should indicate how hard it is to resolve.

That's a great question: How many votes does it take for Atlassian to act on this?

We have a Wiki that works for us, but really like Jira and would like Confluence for the integration of the two. However, this limitation is a show stopper.

I'm sure it's a show stopper for a lot of people. I don't know why they don't address it or even comment back on a plan regarding it.

I have been using Confluence for 1 hour and already I hit this limitation. Immediately voted for this issue. I wonder how many votes are needed tot get this issue resolved.

In the meantime I gonna try the pagetree solution mentioned earlier in the comments...

So this means, Confluence will store the page name as unique key for looking up pages. And it will change this identifier, when I change the page title. So much for decoupling logics and content...
This is really annoying. Voted.

I really cannot understand that this issue is open for years and nothing has been done about it. We use Confluence for technical documentation and there are often pages that have the same name, e. g. "System Requirements", "Installation instructions" etc.

Confluence has so many great features but I find it a bit annoying that there are some rather basic bugs/features that have not been solved for a long time. Examples are broken page links in

macros, no global PDF stylesheet, no integrated support for numbered headings etc.

yep - just hit this one. this is HUGE!! Its so strange how great Atlassian products have the major major flaws that limit the product. Atlassian, please consider the page's location in a heirarchy as the true pk.

on persistence, the page name has the full path. on view or edit, it shows the last node in the path

you save parent1/parent2/thePage. you show thePage, and we edit thePage.

this really cannot be alot of effort.

I'm new to Confluence, and think it's one of the best wiki's I've seen. Except...!

I was really surprised by this design flaw, and even more surprised to find that it's been a reported, discussed, yet never addressed issue for years.

What is going on?
Does the Atlassian Confluence team not consider this a major issue?

Updated affects version list to include...um, everything since the beginning of time up until present day, some 6 years later.

The only saving grace is that one of our developers left us to join
Atlassian here in Sydney. I've tasked Graeme with being my eyes and ears on
the ground at Atlassian and find out once and for all what's going on with
this issue!

JP

PS - I finally get a block of time to work on overhauling our documentation and I spend an hour trawling through 6 years of comments on a fundamental design flaw that have come to nothing. Thanks Atlassian! I suppose now I'll spend another hour trying to get Brice's work around to work.

Truly amazing. If other wiki products support non unique page names, and after 6+ years Atlassian have not dealt with this despite being gifted an at least partial solution by one of their clients, I can't understand why anyone who cares about their wiki design would persist. I suppose for the same reason that I might - that changing to another product is too complicated or difficult to get approved. I'm going to try the workaround, but thankfully I potentially have the scope to move to a better product. Usability is about balancing design tensions - if a solution to this problem impinges on wiki standards, I would suggest it's a fair trade off. The cost of unique names is just too great.

I add my vote too. When following a template (fixed set of pages) to document various software components owned by my team it really hard every time to come up with a new name while we create similar information for each app. We gotta have this feature.

We are really running up against this limitation when our power users who really want to set up a robust page structure are left having to awkwardly prefix their sub pages at every branch. This restriction also seems to fly in the face of software best practice--we want to encourage simplicity and reusability, right?

Wow, this has been an issue for 6 years? I would love to see this implemented too as I use a standard documentation system. Very Limiting currently. Kind of crazy it's taken this long to get to it, I suggest using some of the $60M in funding you just got...

I suggest to combine all suggestions to a more simple one.

All stays more or less how it is now but confluence gets a number of custom fields in addition to pageID and pagettitle in its database tables according to Brice Copy’s suggestions.

1. displayTitle : set the display title
2. navigationTitle : set the navigation title
3. Breadcrumb/pagetreeTitle : set the breadcrumb and pagetree title

If none of the fields got content entered while in edit mode (and those fields would only be visible in edit mode by clicking on something that expands that custom title area) all will work as it is.

For sure linking must be done in common way using the original page title otherwise you will not be able to distinguish if you use page

e.G. If someone did enter content in field 1 just the title to be displayed and printed will change but the rest stays as common. The other will work same way. Field with no content just snap to common page-title.

While providing custom fields you could create a number of additional custom meta-data fields, so that we have something to apply which we dont like to place within a page using macros – maybe using templates – same problem with creator of a page who is seldom author of content – we need more custom fields which are just some additional columns.

The change of coding of confluence would be just the creation of columns within already existing tables.
The rest is simply a small code in front of that code that supplies the pagetitle to be used so that it will get changed according to custom settings and a little design and work has to be done to get this displayed.

… dont shoot … I know, it will not be just that simple but it might be the easiest way to keep the philosophy of confluence standard solution while keeping track with customer demand.

Micah Figone is right. This would solve it, and it is already possible in simple html-implementation. So why not with CONFLUENCE?
I am working on a Support Wiki. I would like to have the same structure for all my products. This is currently not possible, due to the naming restrictions. Really sad and kind of retarding wiht respect to my work...