Description:
When rendering pages with headings to a view format then headings will have different IDs when rendered by Confluence in the browser vs when rendered through the REST API.
This is made worse now that Confluence actually encourages people to copy in the link with the “wrong” ID with this heading link feature.
Steps to reproduce:
- Create a new page (with the default Fabric editor) in Confluence Cloud, add a Heading with the text “This is an example heading”
- Save the page and then click the little link icon that will appear next to the heading on the page view. Save the copied link to that heading somewhere
- Convert this page to
export_view
orview
format via the REST API. This can be simulated via this curl command:
curl --request POST \
--url 'https://your-confluence-instance.atlassian.net/wiki/rest/api/contentbody/convert/export_view' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{
"value": "<h2>This is an example heading</h2>",
"representation": "storage"
}'
- Compare the ID/anchor that the heading has from the REST API response to the ID/anchor that Confluence copied for you in step 2.
Expected result:
The ID/anchor in the link and the ID in the heading match
Actual result:
The link copied from Confluence is something like https://<instance>.atlassian.net/wiki/spaces/<spacekey>/pages/<pageID>/<PageTitle>#This-is-an-example-heading
, which means that the ID of the heading is This-is-an-example-heading
The response of the REST API is something like: {"value":"<h2 id=\"Thisisanexampleheading\">This is an example heading</h2>","representation":"export_view", ... }
which means that the ID of the heading there is Thisisanexampleheading
This means that when a user uses the link that they copied from Confluence in their page and then a third-party app (for example our Scroll PDF/Word Exporters) uses the REST API to export these pages then this link will not work correctly due to the different IDs.