Ri:page reference gets removed in storage format when custom content title is the same as page title

Steps to reproduce:

  1. Create a page “Test 1”.
  2. Create a custom content object with the title “Test 2” and the storage format body <p><ac:link><ri:page ri:content-title="Test 1"/><ac:link-body>Test link</ac:link-body></ac:link></p>
  3. Rename page “Test 1” to “Test 2”

Expected result: Custom content gets updated to link to page “Test 2”: <p><ac:link><ri:page ri:content-title="Test 2"/><ac:link-body>Test link</ac:link-body></ac:link></p>

Actual result: ri:page element gets removed, breaking the link: <p><ac:link><ac:link-body>Test link</ac:link-body></ac:link></p>

It seems that when the page reference is updated, Confluence thinks that the custom content is linking to itself, because the page that it is linking to has the same title as the custom content itself.

This also happens on Server.


Hi @candid,

I’ve been having a look at this and I’m trying to see how you made the custom content object in Confluence Cloud. In server it would be a user macro, but Cloud is more involved. Can you share the steps you went through to create it? Is it from this documentation?

I think these bugs might be the same issue, can you have a look?

If they are similar enough, I’ll update the description otherwise I’ll keep checking further to see if it’s a known issue or needs to be logged as a new bug.


This has been “forever” like that on “server” and we have not realised it is a bug.

(in ConfiForms app we have some code that handles this for us (and the users) when the app is asked to create pages)
BTW, I think it is still the same in Confluence 7.x+ ( https://jira.atlassian.com/browse/CONFSERVER-57794 does not mention this in affected versions)

I had a look at those issues and I don’t think it’s about the same thing. The issue described there is about a same-space <ri:page> (without an ri:space-key attribute) staying same-space even when copied to a different space. My issue is about the whole <ri:page> element disappearing (so a page reference is becoming a same-page reference).

We are not using user macros on Server. We are adding a content type using something like <content-type key="document" name="Scroll Document" class="com.k15t.scroll.documents.document.DocumentInstanceContentType"/>, with the class extending com.atlassian.confluence.content.custom.BaseCustomContentType. I couldn’t find any documentation for this, implementing custom content on Server always involves a lot of guesswork, trial&error and reading the Confluence source code. We are creating the custom content object using customContentManager.newPluginContentEntityObject("k15t-scroll-document-versions-for-confluence:document") and then saving it using customContentManager.saveContentEntity(cceo, null);.

On Cloud we are following the documentation that you linked. Our configuration looks something like this:

    "modules": {
        "customContent": [
                "key": "document-family",
                "name": { "value": "Scroll Documents" },
                "uiSupport": {
                    "contentViewComponent": { "moduleKey": "k15t-docs-document-manager" },
                    "listViewComponent": { "moduleKey": "k15t-docs-documents-overview-page" },
                    "icons": {
                        "item": { "width": 16, "height": 16, "url": "/static/assets/imgs/documents_icon_item.svg" },
                        "list": { "width": 24, "height": 24, "url": "/static/assets/imgs/documents_icon_sidebar.svg" }
                "apiSupport": {
                    "bodyType": "storage",
                    "supportedContainerTypes": ["space"],
                    "supportedChildTypes": ["attachment"]

We are then using the Create Content API to create such content.


Hi @candid,

Can I get you to log a MIG ticket in JAC with as much information as possible, and then link it to [MIG-464] Support migration of Scroll PDF Exporter ?

This way we can track the specific fix that you require.


The issue is now also being tracked as MIG-563.

I have found a second, slightly similar but different case where this problem occurs.

Steps to reproduce:

  1. Create a page “Test 1” and a page “Test 2”.
  2. Create a custom content object also with the title “Test 1” and the storage format body <p><ac:link><ri:page ri:content-title="Test 1"/><ac:link-body>Test link 1</ac:link-body></ac:link><ac:link><ri:page ri:content-title="Test 2"/><ac:link-body>Test link 2</ac:link-body></ac:link></p>
  3. Rename page “Test 2” to “Test 3”

Expected result: The link to page “Test 1” stays intact, the link to “Test 2” gets updated and points to “Test 3”.

Actual result: The link to “Test 2” gets updated, but the link to “Test 1” breaks. The resulting body is: <p><ac:link><ac:link-body>Test link 1</ac:link-body></ac:link><ac:link><ri:page ri:content-title="Test 3"/><ac:link-body>Test link 2</ac:link-body></ac:link></p>.

As you can see, the link from custom content “Test 1” to page “Test 1” also broke, even though page “Test 1” itself was not touched. So the problem seems to be a bit broader than I had originally realised. Whenever a page that is linked by a custom content is renamed, any link by that custom content to a page that has the same title as the custom content breaks. Regardless of whether the renamed page itself has the same title as the custom content.

1 Like