How to change Confluence to duplicate page names

Question

I use Confluence for documentation, both end-user documentation and internal development documentation.

The problem with Confluence is that it does not allow duplicate page names, since the URL consists only of the name, not the entire tree structure.

Is there any way to change this behavior?

There is a plugin that does this and more. The “much bigger” problem is the problem because this plugin is quite expensive, especially if only one of the many functions will be used ( https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-versions ).

Answer 1

Atlasian states that they will not change this behavior. There are plugins like Scroll Versions to get around this, but you can revise your wiki structure there.

Does Wikipedia allow multiple pages with the same name? This is not true. If you get rid of the thought of hierarchical order for your wiki and instead start using the search function and tags, it all makes sense.

We had the same discussion when setting up documentation for our projects. What if you have 150 pages with the title "Documentation"? Try searching if you do not know the exact name of the product.

Answer 2

We had the same problem when adding “empoyee virtual folders” to our wiki. We wanted to change the following page structure:

Employee 1 Personal Data Contract Data Training ... Employee 2 Personal Data Contract Data Training ... Employee X Personal Data Contract Data Training ... 

We solved this with a dirty, but very effective workaround: first we made unique page names by adding prefixes for employees:

 Employee 1 Employee 1 - Personal Data Employee 1 - Contract Data Employee 1 - Training ... Employee 2 Employee 2 - Personal Data Employee 2 - Contract Data Employee 2 - Training ... Employee X Employee X - Personal Data Employee X - Contract Data Employee X - Training ... 

We defined our own "tag" to mark the part of the page title that should not appear in the confluence interface:

 Employee 1 [hide]Employee 1 - [/hide]Personal Data [hide]Employee 1 - [/hide]Contract Data [hide]Employee 1 - [/hide]Training ... Employee 2 [hide]Employee 2 - [/hide]Personal Data [hide]Employee 2 - [/hide]Contract Data [hide]Employee 2 - [/hide]Training ... Employee X [hide]Employee X - [/hide]Personal Data [hide]Employee X - [/hide]Contract Data [hide]Employee X - [/hide]Training ... 

The rest is done using JavaScript-Magic, built in through the Confluence Admin Admin> Custom HTML :

 <script>(function() { var expr = /\[hide\].*?\[\/hide\]/g, blacklist = ['textarea', 'form', 'pre', 'script', 'style']; $(document) .ajaxSuccess(hideTextParts) .on('ready', hideTextParts); function isChildOfBlacklistedTag(node) { while(node = node.parentNode) { if (node.nodeType === Node.ELEMENT_NODE && blacklist.indexOf(node.nodeName.toLowerCase()) > -1) { return true; } } return false; } function hideTextParts() { var root = document, walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT, null, false), node; while (node = walker.nextNode()) { console.info(node.parentNode); if (expr.test(node.textContent) && !isChildOfBlacklistedTag(node)) { node.textContent = node.textContent.replace(expr, " "); } }; } })(); </script> 

The blacklist ensures that the "tag" is not hidden where you need it to appear. For example, in the title field of the page editing screen and in the CSS editing field in space management. You can go to

Answer 3

My company also had this problem. The best way to deal with this situation is to create one workspace for each “context”. IMO, if you need to insert a prefix on every page that you create, it looks like context demarcation. Therefore, it is best to embed each context in your own Confluence space.

Toolbar - Space 1 - My Page
Toolbar - Space 2 - My Page

When you create spaces, you can classify them, so you can insert labels such as "project", "database", "application", etc. https://confluence.atlassian.com/display/DOC/Using+Labels+to+Categorise+Spaces

Hello

Answer 4

Confluence is not just a wiki that seems to foster the use of a documentation hierarchy. A hypothetical example might be:

 MongoDB Installation Linux Windows Mac Security Data Model 

I would like to keep the page title short, and not call them like "MongoDB -> Installation -> Linux".

But if I just keep them short, then every clash of names happens between this and other documentation.