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

Your proposal breaks wiki links - each page should have a unique, human
friendly, identifier. I wouldn't want it any other way.

Note that we've been using our Pagetree patch for more than a year now
and it works beautifully for us.

Now if only Atlassian would pick it up, that would be fantastic

Brice

A way of accomplishing this with relatively little work would be to make it so a page name and the URL of said page be different. That way you could still have a nest page display in the tree as the same name but the actual page url is different.

Sehr geehrter Absender,

leider bin ich zur Zeit nicht im Büro und kann Ihre Nachricht momentan
nicht bearbeiten. Ab dem 27.09.2010 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 2010/09/27. 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

This is a critical issue for us as well, and a major showstopper.

Page-name uniqueness is fine – all we need is that pages display an optional user-defined alias, which would also appear in other contexts, such as the pagetree. It is no different to providing an alias for a URL – it is simply a text label that avoids having to display the full complexity if a unique page title such as "User Guid - Tools - SomeTool - Overview".

The CERN PageTree 1.15 patch sounds very promising. We'll install it and check it out.

Atlassian have been very poor at following up this issue. I find it unacceptable that JIRA tickets relating to this issue are over six years old and there is no feedback from Atlassian on how they are planning to fix this issue. I'm persevering with Confluence but it's a difficult tool to love – this kind of issue (along with other issues like limited support for attachment file formats, buggy page tree, no per-section page editing) makes it dificult to enjoy using Confluence as a day-to-day alternative to Mediawiki.

Just voted too. It looks like really desired feature for us.It would be good to have possibility to create the same name pages at least in different branches.

We installed Confluence one week ago and it took 1 hour for our key users to hit that issue, so it has our immediate vote !

As the post is now 5 years old, would it be possible to summarize somehow all the still valid possible work-arounds found in the comments ?

Any schedule in the near future ?

While I do think this is a very important feature, I am concerned that an approach of linking to nested pages in the form "http://server/ancestor page title/intermediate page title/child page title" will quickly become insanely long, breaking URL limitations and of course impossible to type. People are used to nesting their pages many levels deep, and page titles of 200 characters each are no rarity.

So that can't be the normal way of accessing a page. It could be used as a differentiator when there are multiple pages by the same name, keeping the length limitations in mind. However, my feeling is that the main point of same-named pages is for structure, which people will mainly navigate within Confluence. Bookmarks and email links can just use the tiny URL (or even the pageId URL if you want). So I'm not sure we should focus on the linking mechanism - the key piece is removing the uniqueness constraint, and introduce one by (parent_id,name) instead, plus a UI for easily picking the desired page from multiple choices when users access a non-unique name-based URL (needs to show the entire hierarchy above the page!).

We also have problems with this issue.

Is there any schedule for it?

> Once you get over the fear of having too many spaces to manage,
Interesting, I'll have a look at sub-spaces plug-in.

Clearly CONF-2524 would require a lot of effort. I assume Atlassian does not see a positive ROI for the majority of it's customers. For a small subset of extremely large sites (ex. 65,000+ users) you can imagine the tens of thousands of spaces necessary for one space per project.

That said, thousands of spaces do have benefits, and it may be less disruptive to modify Confluence in ways that enable massive number of spaces and also eliminate the known adverse affects of thousands of spaces on usability, scalability, and management. (Example - NNTP servers figured out ways to give users access to tens of thousands of newsgroups, without giving a user a drop-down selection that lists all of them. )

Cheers,
Tim Colson
SW Architect for an Enterprise Scale Wiki at Cisco Systems

There's a number of other plugins that allow sub-spacing, not sure if they all use the same mechanism though:

• Metadata 2 plugin - provides sub-space aware macros for breadcrumb trail and space hierarchy. Unfortunately requires a macro to be added to wiki pages in order to set sub-space (not ideal).
• Theme Builder 3.x - option to set parent space in space admin, uses same storage method as metadata plugin (but better way of setting the parent space).
• RefinedWiki theme - allows grouping and nesting of spaces, looks really impressive. Not sure if it uses common metadata storage method for the settings.

Gunther's post is an echo of many similar comments over the life of Confluence. We have worked around this limitation by adopting a naming conventions plus use of cards/decks via the composition plugin. We've also found the subspace plugin to be a real lifesaver. Without cards/decks and subspaces, we would have abandoned Confluence.

Naming conventions alone are not enough, particularly given that such restrictions add complexity which users often dont understand.....and achieving compliance is a real problem within enterprise. Page names should be easy, not a major stumbling block. Although I love Confluence, I'm astounded that this issue has never been properly tackled by Atlassian. It seems so obvious that I can only conclude it would be REALLY hard to fix. Like "start again from scratch" HARD.

That said, I'd encourage Gunther to explore taxonomies based on creating a space for each project. That's what we do, using the subspace plugin to manage menus and heirarchies, plus decks/cards to manage anything repetitive within the project. The subspaces plugin really is very useful if you can make it fit your needs. Once you get over the fear of having too many spaces to manage, it works very well, especially when copying existing spaces as templates for new spaces. Completed projects are archived by remapping (via subspace config) to a different parent space (for example, if a project is completed, change it's parent space to "Archived Projects Dev Unit 1"). Since we use the subspace plugin to generate our main menu heirarchy, remapping parent/child spaces automagically sorts out menu changes. Our users love it.

But even with all of the above working beautifully, we still have to train our users on the namespace limitations. That's because we will always need child pages. The good thing is that subspaces and decks/cards have really helped to minimise namespace problems by reducing the number of child pages within each space.

PS: We like Brice's pagetree!

Let me explain our situation ...

We have an IT organisation consisting of about 20 (more or less) independent dev. units. For each of them, a space was created.
Each unit manages from 10 to 50 projects, and has between 1 and 30 unique clients. The overall structure is that one project can be for multiple (internal) clients, and a certain client can have multiple projects => a matrix structure is needed to record this information.

Now, each project has pages like "requirements overview", or "project contact details", ...
For each client we have pages like "contact details", "project list", ...

As such, we need a way to have, within one space, multiple pages with the same name
...unless of course, someone can show me a completely different approach ...

(which can not be naming the pages something like "projectX_requirements_login_comments" or "clients_clientX_generalInfo" as most users will simply not accept this).

regards,
Gunther.

Confluence is a wiki, it is quite practical to have uniquely named pages in many cases.
Our users complained about this at the beginning but now they are used to it, and the patched Pagetree plugin we have make navigation very clear.

I do agree that the possibility to attach folders (with static HTML and CSS, for instance maven generated project sites) would be a nice plus in certain cases. But I would hardly call the lack of support for same-named pages within a space a showstopper.

same here ... this could be a show stopper for us as well ...

Just started to evaluate Confluence and the issue of not having possibility to have many sub-pages with the same name bit me after just 30 minutes of usage And I don't like the work-arounds...

Created a stand-in replacement of the standard Pagetree plugin (patched version 1.15).

Much nicer to install (simply remove Pagetree EN 1.13 if you had it installed, then upload pagetree.1.15.CERN, it will replace the standard pagetree plugin).

Jep, you're preaching to the choir here. Even if we could put all our files into such a special folder as a workaround, we will surely come to a point where this limitation is going to hit us. We work very process-oriented and if we want to document them in Confluence, it's going to be hard as all processes share names of components.

But it would at least help a LOT for the files even. I also know the situation you're in. I try to replace our current fileshare as I saw the potential of linking Confluence with other Atlassian products for our development team. I spent several weeks and months making cases and configuring our test installation. And when I finally convinced everybody and wanted to migrate data over as a "load test" I ran into this limitation. You can imagine how inconvenient that was.

So, I hope that they'll at least have something for the files. It would be a solution we could live with and work around the limitation for text pages.

Chris

Your proposed solution would work for me, in this instance, since we are both working with file repositories. And considering that supporting unique pages within a space is very 'difficult', this proposed feature does not run head on into that limitation.

Having said that, not everyone running into this problem is using a file repository and the page hierarchy really does require duplicate names. If this is the case, then the unique page problem still exists.

I'm pretty much open to all solutions at this point. I've been 'selling' the Atlassian tools pretty hard to my company, so much so that I sound like I'm an Atlassian sales rep, but this issue is much more than a minor inconvenience now.

Simon

I understand your point. We wanted to do the same thing with our share drives, since Atlassian positions Confluence as the perfect substitute: put everything into Confluence and make a nice, integrated intranet together with our files.

I contacted one of their sales engineers and he was very helpful, even if he said that this "name duplication" is buried very deep, and he meant VERY DEEP in the core architecture of Confluence. So I came up with another idea. See my post just above yours, with a link to a feature request that would solve at least our company's desire to move files into Confluence away from share drives or SharePoint.

If you're interested, please vote. Thanks.

Honestly, I cannot understand why not more people are running into this limitation and would want to have a solution. Maybe nobody actually wants to replace their whole intranet, be it web stuff and share drives, files and SharePoints with just a neat, cool solution that just works such as Confluence.

We are in the middle of transitioning all of our knowledge bases into Confluence. I was moving one of our document repositories into Confluence via WebDav copy, and constantly ran into 'Error copying' when I reach certain folders. It finally dawned on me that it was a duplicate name issue that was preventing the folders from being copied. Now, I'm stuck on finding a solution for moving the document repository over from Sharepoint to Confluence.

We realized that it's not necessarily pages we want - and consequently not the ability to create pages with duplicate names. We want to be able to create subfolders to store the documentation we produce for our standardized project phases.

So actually our company doesn't need the pages Confluence creates when creating a folder via WebDAV. What we need is a kind of special folder we could put a file hierarchy into. Like a dimensional gate that goes to a normal fileshare, suspending the normal Confluence behaviour. This way, we could have our different project pages that all have a different name. Below these project pages we could then have our "fileshare areas" where folders of the same name can happily exist as it does not interfere with the unique page naming of Confluence.

The real benefit is that one could profit from full-text indexing, Word to HTML rendering and other goodies in Confluence. And you can still use Confluence to create pages with all the Macros and Widgets. A perfect coexistence.

Maybe it's a "fileshare area" some people want. Of course some people need to create pages with duplicate names, but I guess some might find this idea interesting. Instead of creating huge amounts of spaces to avoid naming collisions and having to install sub-spaces plugins to keep them organized, it might be easier having something like a special area on a page where you can create files and folders instead.

I created a feature request, maybe some of you are interested.
http://jira.atlassian.com/browse/CONF-18362

A big vote from our company as well.

We, as many others too, would like to organize our projects that have the same structure. Every project has a unique name, but then we have pages with offers, documentation, final deliverables and so on.

As we don't want to crowd the intranet with a huge amount of spaces, we just created one space for our projects. And now, trying to import our fileshare, of course this fails miserably.

I'm surprised that this issue has been around for 5 years now and no functionality has been added in that regard. I know this feature is not as sexy as, say, drag and drop in Confluence 3.1, but it is a professional need companies have. As far as I know Confluence is an enterprise wiki, and enterprises do have these needs, even if they're not hip and web 2.0.

Confluence really kicks the butt of all other systems we tested. That's why we care so much about this feature. Handling file structures is generally a little clunky in Confluence (even though Atlassian likes to say "forget your shared drives, use Confluence").

So I'd like to add a strong vote to this topic.

sorted-children would be a terrible choice for a pagetree ... the data needs to be loaded dynamically, sorted-children would require you to load every page up-front.

If you're using a recent version of Builder (latest snapshot of 3.3.6 or 4.x) try the sorted-children macro with some CSS applied. It adds a 'current' class to the path to the current page.

@Brice: See if you can get in touch with Alain Moran (probably best through Builder forums on our website) as he might be able to do something with regards to pagetree2, etc.

Pagetree2 is one of the remaining commercial components in Builder so we can't give out its source. It's also on our 'replace with something less crufty' to-do list. We'll likely be replacing it with something based on the sorted-children macro (with some extra CSS and JS to turn the unordered list of pages in to a nice treeview).

Indeed, as advertised, it only patches

(couldn't get hold of the pagetree2 code - if anyone knows if it's up for review I would be interested).

Concerning your formatting problems, I expect for instance UL and LI margin issues. We fixed those with simple CSS such as the following.
Your mileage may vary however, I suggest we take this offline because this is becoming rather specific (my email is on my Atlassian profile).

.plugin_pagetree div ul {
  padding: 0px;
  margin: 0px;
  line-height: 0em;
}
.plugin_pagetree ul {
  width: 100%;
}
.plugin_pagetree li {
  text-align: left;
  line-height: 0.8em;
  margin: 0px;
  padding: 0px 0px 0px 13px;
}

.plugin_pagetree span{
  font-size: 0.9em;
}

Okay, so I have ThemeBuilder installed and running and I'm messing with a custom theme.

If I add a LH navigation bar, it puts in by default

which doesn't work with your modified plugin.

If I change this to

I have some terrible formatting problems.

Do you have a ThemeBuilder theme that works nicely with your macro you could share?

Brian : This plugin assumes that you are using Adaptavist Theme Builder for instance, where you have full control over which theme elements you wish to display. In your case, you would replace the standard built-in page title by the

macro.

Hmm...okay. So how would I get this title to display in place of the one that comes from the page template next to the logo? Can I use this in the VM for the page? What about in the HTML title?

Right now my page has the default title and the alternate one.

I really appreciate the help.

Sorry Brian, there's one last macro I did not mention :

Have a look in the help for this macro.
It will use only the Display Title (the navigation title is purposefully ignored).
Make sure to download the latest version of the plugin I uploaded.

Updated version, that takes web contexts into account for the breadcrumbs.

Thanks. I got it installed, reconfigured and restarted, and I added this markup to a test page:

If I set displayTitle, the PageTree navigation changes, but the page title doesn't. If I set both displayTitle and navigationTitle, the navigationTitle is what is shown in the pagetree. However the actual title shown next to the space logo and as the HTML title of the page doesn't change from the page name.

What am I doing wrong?

Brian, here goes, I attach a packaged confluence plugin. However, please note this code is far from production quality, so you will have to rebuild from source at some point. I think the Atlassian developers doc has some good pointers on Maven 2.

After deployment, disable only the "naturalchildrenaction" in the built-in Pagetree plugin, then restart Confluence once.

Brice, I don't know how to build Confluence plugins. I grabbed Maven and tried just running 'mvn.bat' in the unzipped plugin directory but it blew up. Do you have a compiled version you can share, or tell me how to build this myself?

M. Hansen : Sent by email to your address. I've also attached a snapshot ZIP to this issue (to be compared to Pagetree 1.13).

If you're interested, the code for the patch is freely available, but not supported I'm afraid.

Brice, I'm interested in having a look at your patch. Where can I find it?

Hello,
Here at CERN we have implemented a patch to the Pagetree plugin (v1.13) which adds support for two properties :

• Display Title (non unique title to be displayed on the page)
• Navigation Title (non unique title, to be used only for pagetree and breadcrumbs, in preference to the display title).

We then have three extra macros :

• displayTitle : set the display title
• navigationTitle : set the navigation title
• navigationBreadcrumbs : Theme Builder type breadcrumbs that use the two properties above

Plus one listener, in charge of clearing the title properties when the macros are not used on the page anymore.

This is a low-tech solution, using built-in Confluence features, which works quite well, it'd be great if these ideas could be included in Confluence.

If you're interested, the code for the patch is freely available, but not supported I'm afraid.

We just discovered this issue ourselves. At a minimum we really need to have an alternate "display name" for a page which would show in the treeview and page info.

I agree that this issue identifies a strong need for Confluence.

I've recently come up with a decent, but not perfect, solution for this problem, using the Reporting plugin. About a year ago, that plugin added several 'suppliers' that employ regular expression matching, which is an angle to tackle this problem.

Will post an example when I've finalized my ongoing project.

That's going to be all the harder due to the URLs used by status updates - in Conf 3.x, go in to your network tab (in profile area) and find someone who's recently posted a status update - there should be a little link icon to the right of it, click on it and look at the URL, it's in this form:

www.whatever.com/display/status/<username>/list

See the problem?

...except that of course you would want to use a forward slash as separator to be consistent with URLs, and not an escape character, aka Windows-backslash

Assuming you have a space TEST with a child page of TEST1 and TEST2, linking to those pages is is defined as as [TEST1] and [TEST2] respectively. However, if both of those pages wanted to have a page named "Home", why not force the use of a parent page designator so the links would look like this – [TEST1\HOME] and [TEST2\HOME]. If no parent page was present (parse for the '\') then the system would find the first page with a title of HOME and present that.

If the space were invoked then, of course, the markup would still be [TEST:TEST1\HOME]. All other parsing, rendering rules would remain in place.

At least that would be consistent with what is done outside of the Atlassian/Confluence frameworks in regular html pages.

Closed dupe of CONF-5926, with 48 votes as of October 12, 2009.

I think I understand some of the complexities of fully implementing a solution to this problem and there is apparently no easy solution.
So, maybe I am being too simplistic. But, I believe my team would be happy with a first pass at a solution that allows the user to, by hand, specify an optional "Displayed Title" in addition to the page "Title" that is currently entered when you add a page.

@Mark DeSimone

Is there a way to import them and have the titles automatically change to be unique or use a page ID instead of a name?

You could try using the UWC. You'd need a developer, but the customization would be fairly trivial. You'd want to create your own converter module, and add a converter to take advantage of the Page Titles Framework. You'd probably also need to add a converter to change the links to internal pages to reflect the name change. Here's some relevant links:

• Universal Wiki Converter
• UWC Developer Doc
• UWC Page Titles Framework

Cheers,
Laura

This is also critical to us since we are using a file server and trying to migrate it to Confluence and since file servers allow the same names, it will not import via webdav. Are there any workarounds until this is fixed? Is there a way to import them and have the titles automatically change to be unique or use a page ID instead of a name?

Just been caught out big time with this limitation.

Had aggreed to use Wedav plugin to move Commercial side of organization off NT file server and onto Confluence. No sub folders within a space can have the same name as they are in effect pages.

This is just dumbfounding. Another major kick in the ass from Confluence. These limitation needs to be fixed ASAP.

Update 2008-Jul-11: Tim updated this description to be more succinct, readable and incorporate some ideas from the three and a half years of comments below.

The thread Brent Feike links to has a very succinct and coherent post by the OP that I endorse.
My colleague and I pushed really hard for the purchase of Confluence, and playing around with an evaluation copy today were stunned to find this particular limitation.

With only two of our projects entered, I already can't easily refer to an 'Invoice' feature, since both have one. (Of course being nothing alike). Add my vote to fixing this.

Space can have the same Title, because they are linked to by ID. Page's can't, because they aren't. The rich text editor is not a lot of people's primary editor – in fact we highly recommend that people who do a lot of editing use the wiki markup editor, and that would still require it being made significantly more complex than it is now; even with a "insert link" resolver.

When viewing the page markup as a person who didn't create the content and seeing that wiki syntax, how am I supposed to know which Page B is actually pageid 66549? I would have to go off and hunt to find out. This for a lot of users will be far less user-friendly and knowing that Page B in Space X can only be one page.

Personally I think the link instead of being [Page B] should be [Home > Parent > Page B], as if you wanted to link to ID 123 you could do $123.

PS: Page IDs can (and do) change, especially when exporting / importing content ... possibly when moving too.

In this screenshot you see the possibility to choose between two spaces with same title. Why should this be basicly different to pages?

This dummy screenshot shows how the selection of a page could look like when page titles are not unique. A kind of breadcrumb or a hirarchy could help to find the right one.

Spaces can have same Title, identified by ID (= space key)

Dan,

for the users there is no need to investigate and fill in any page id (same when editing a page: nobody cares about the page id). The user marks any text in his page, click on "Insert Link", choose the page out of the list (here you need to show a kind of breadcrumb for the orientation which page of the double named is the right one, maybe combined with a kind of preview of the targeted page).

The wiki syntax created could be like this:

[Link to Page B|title=Page B|pageid=65549]

See additional my screenshots

Maybe as a first step towards support for this might be allowing links to point to the full path of a page, i.e. [/SALES/Sales Reports/2008/First Quarter] which would link to the "First Quarter" page that matches that parentage. At the same time, the insert page browser could be updated to insert these full paths rather than the current behavior.

At this point the user would see no difference, but also have no new functionality. This is effectively what's discussed above.

If another page was created elsewhere with the name "First Quarter", for users without edit rights, the link should render as link to an "ambiguous page" page - which could be like a page search, listing the various pages, explaining what an ambiguous page is, and why/how you got there.

If the user can edit the calling page, each page listed could have a "update '2008 Sales Reports' to use this page" which would replace the [First Quarter] with the fully qualified name.

Also, under space admin there could be a new tab with a list of all ambiguous pages.

Would be great to see something like this land in confluence sometime...

It's down to these "normal" users that this constraint was put in place in the first place for page linking. When you link to a page you use [Page Title], if that space has two pages with [Page Title] then the syntax needed to link to the right page suddenly becomes much more complex.

Are you suggesting that forcing people to use [$PAGE_ID] would be more user-friendly?

There are, of course, alternative linking methods (as discussed in this issue) but all of them are definitely less user-friendly. I am of course in favor of the motivation behind this issue also – I just understand the implementation implications.

It is possible to have spaces with the same name/title. Why not pages with the same name/title? Both, space and page, have an ID. That's enough to identify the data. This is unlogical.

Name spaces are not very useful due to "normal" users (non-IT-users) who do not know anything about that. You have to make the system user-secure, not the user it-secure.

Having just started looking at Confluence after having used PmWiki I think this is a critical feature that is missing. While PMWiki also has a limitation on unique page names within a space (or group as PmWiki calls them) they do allow you to define a different display title for the page which means for the average user who is just viewing rather than editing, things can be made to look more sensible.

PmWiki also has a plugin which adds the concept of subpages to provide some workarounds for not having full hierarchical naming. Perhaps some of the concepts mentioned here http://www.pmwiki.org/wiki/Cookbook/SubgroupMarkup could be implemented within Confluence as an alternative to changing the way the naming works.