Copy Space, Copy Page Tree do not rewrite the space key in some links

Owned by Ture Hoefner (Unlicensed)
Last updated: Dec 05, 2019
3 min read

Both Copy Space and Copy Page Tree currently do not rewrite links for the space key if they are "a href" links (as opposed to "SFXML a:link" links). 

  • The space key is the unique string/key used to identify the space that a page or other resource lives in.
  • When a space or page tree is copied from one space to another space the space key in links is rewritten to change it from the source space key to the destination space key.
    • Thus, links within a space continue to work in a new copy in a different space.

If a space key is not rewritten in a link then the symptom you will notice is that clicking on a link in a new space will go back to the page/resource in the original space, not in the new space.

The cloud apps Copy Page Tree and Copy Space have enhancement request records to add support for rewriting space keys in "a href" links.  See CPTC-60 and CSOD-38.  Upvote them if you would like to have "a href" rewriting in these apps.

There is a workaround, see the Workaround section

The Copy Page Tree and Copy Space apps do generally rewrite links so that they point to the new space when you copy a page tree or space to another space but it does not rewrite "external" links.

By an "external" link we mean a regular a href link. View the Storage Format of a page with links on it to see the links. On a page with links, if you click ... --> View Storage Format you will see the "Storage Format XML" (SFXML) markup for the page.


The Copy Page Tree app rewrites the space key for page links.

BEFORE COPY to a different space:

<p>Link to page in this tree: <ac:link ac:card-appearance="inline"><ri:page ri:content-title="Child Page" ri:version-at-save="2" /><ac:link-body>Child Page</ac:link-body></ac:link> </p>


AFTER COPY to different space:

<p>Link to page in this tree: <ac:link ac:card-appearance="inline"><ri:page ri:space-key="delTureCopy3" ri:content-title="Child Page" ri:version-at-save="2" /><ac:link-body>Child Page</ac:link-body></ac:link> </p>


The copy app does NOT (currently) rewrite "regular" "a href" links:

<p>Link to page in this tree, edited to have title: <a href="https://myinstance.atlassian.net/wiki/spaces/TS/pages/102334476/Child+Page">Child Page Link</a> </p>

That link would remain the same after a copy operation, so the new copy will still link to the origin space.


Some people have edited their links so that they became "a href" links instead of SFXML "ac:link" links.  The may not realize that they have changed the links from SFXML "ac:link" to "a href".

One reason that people are editing SFXML "ac:link" links is because there is an Atlassian bug that incorrectly renders ac:link page links for anonymous users (CONFCLOUD-68023).

The edit their ac:link page links to add display text so that the link will always show the page title instead of showing an ugly link for anonymous users.

If you edit a SFXML link and it turns into an "a href" link then perhaps you can use the workaround that Sven used here: Internal links in Confluence Cloud | Atlassian Community

In Sven's case, he had edited SFXML links to workaround the anonymous user issue of CONFCLOUD-68023 and then ran into the problem of that turning the link from "ac:link" to "a href". To workaround that, he edited the link to delete the protocol and domain so that it became a relative link:


EDIT THIS:

https://myinstance.atlassian.net/wiki/spaces/TS/pages/102334476/Child+Page


TO BECOME THIS:

/wiki/spaces/TS/pages/102334476/Child+Page

and Confluence turns the link back into a SFXML ac:link. Then it will be properly rewritten to point to destination space for a space copy.

This workaround of using a relative URL works for Confluence Cloud.  When editing a page link in Confluence Server I have not been able to get it to remain a relative URL:  when saving the page it appears that Confluence prepends the protocol and domain to put it back to being an absolute URL.  Further study is necessary to figure that out for Server.  This issue really applies more to Cloud, however, because only in Cloud are folks having to edit their page links for the Confluence Cloud bug related to ugly links for anonymous users (CONFCLOUD-68023)

If you are editing SFXML links because the original link renders ugly for anonymous users then upvote the Atlassian bug CONFCLOUD-68023. Upvoting issues plays a major part in prioritization and speeding up a fix.