Copying page messes up links to anchors/headings Edited

[Mirco Stange]

I have a page with a number of links that point to anchors (headings) within the same page. This is using the "#heading" syntax.

However, when I copy the page, all links are messed up, so that instead of refering to "#heading", they refer to "Copy of pageX#heading". Even more annoying, the link text is also updated. 

Is this a known defect or something that can be prevented somehow?

[Thomas Schlegel]

Hi,

I don't think that this is a defect. If I copy a page with "self-referencing" links, I would expect that these self-referencing links keep their self reference. They should link to the same page where they are included and so they also do that on the copy. 

[Mirco Stange]

Not sure if you agree or disagree with my statement. 

I did more testing and am fully confused. 

The source page has 

<ac:link ac:anchor="Introduction" />

(where introduction is a heading on the same page). This shows as

Introduction

When I copy the page it shows as

Copy of PageX#Introduction

However, when I then edit the copied page the copied page goes back to normal (markup and display) - even without applying any actual edits.

I would consider this to be an error.

[Thomas Schlegel]

I don't understand the problem, to be honest. My original test page looks like this:

<h1>test</h1>
...
<p><ac:link ac:anchor="test" /></p>

If I copy the page and look at the storage format, it looks exactly the same.

If I look at the target of the link on the original page, it refers to:

http://<confluence-url>/display/SPW/links+anchor+links#linksanchorlinks-test

and the copy:

http://<confluence-url>/display/SPW/Kopie+von+links+anchor+links#Kopievonlinksanchorlinks-test

[Robert Reiner [smartics]]

If I understand Working with Links correctly, it seems to me that

page#anchor

is the implied form of

#anchor

iff  'page' is the current page.

So it may be considered an issue to not fully normalize the link, although the rendered result is - as Thomas has shown - identical.

I suppose M.S. encounters an actual problem for a use case due to Confluence not 'normalizing' the links on the copied page fully. Maybe this could provide some more context for this question and therefore we could understand why this should be considered an error?

[Mirco Stange]

If I copy the page and look at the storage format, it looks exactly the same.

It does not for me. The storage format as well as the link text that is displayed changes.

See how it adds a <ri:content-entity ...> during the copy and that disappears when "editing":

[Mirco Stange]

Confluence 6.0.1 by the way.

[Robert Reiner [smartics]]

Ok, the case you show is a bug in my opinion.

On Confluence 6.1.3 I cannot reproduce the problem. Maybe this is a bug already fixed?

[Mirco Stange]

I will consider updating to 6.3.x. Hopefully the issue goes away.

[Thomas Schlegel]

Thank you for the detailed information, now I understand your problem. 

I hope, this will be gone after updating, good luck!

[Mirco Stange]

I did a quick update to Confluence 6.3.3.

There problem is still there...

How can attention from Atlassian be pointed to this?

[Thomas Schlegel]

You can open a support case here: 

https://support.atlassian.com/contact/#/

[Mirco Stange]

I am on Starter License, so it points me back to the forums :-(

[Robert Reiner [smartics]]

I just checked with a 6.3.3 and I cannot reproduce the problem.

I created a page with a local link, copied it and the label of the link does not contain the anchor.

I downloaded the WAR with the Atlassian SDK and started the Confluence Server locally.

Puzzling ...

EDIT: Synchrony is off in this test environment.

[Thomas Schlegel]

Hi @Ann Worley,

are you able to help her / him (don't know what "M.S." stands for) ?  

[Ann Worley]

Yes, @Thomas Schlegel I am investigating. Thanks for the heads up.

[Ann Worley]

@Mirco Stange I could not reproduce the issue on my Confluence 6.3.3 test instance so I created a support ticket for you so I can take a closer look. You should get an email from me shortly, asking for logs.

[Ann Worley]

For anyone else experiencing this issue, similar behavior has been reported as a bug:

An anchor link's name changes after editing the page with Collaborative Editing switched on or set to limited

M.S. is going to turn off collaborative editing to see if that fixes the issue for his instance.

[Ann Worley]

Turning off Collaborative editing eliminated the issue M.S. was experiencing with linking to anchors when copying or editing.

Collaborative editing can be set to Off mode at Confluence Admin>Collaborative Editing>Change mode.

[Stephen Kairys]

@Ann Worley

Has this issue been logged as a bug in JIRA? We've just discovered we've been exposed to

https://jira.atlassian.com/browse/CONFSERVER-51690/

and we're turning off Collaborative Editing b/c of it. We would like to turn it back on once 51690 is fixed. However, unless we're confident that this "copy" bug won't affect us, I'd be reluctant to turn it back on.

Thanks.

[Ann Worley]

I understand you are concerned that links will break when copying pages with collaborative editing on. 

In response to this thread and the related support request I added a comment to the bug report to let the dev team know it is being reported on copies as well as simple edits: An anchor link's name changes after editing the page with Collaborative Editing switched on or set to limited

[Stephen Kairys]

Oh, you mean your comment from last year?

I hope this bug can be fixed ASAP. If the page I'm currently editing broke, who knows what else broke? What's the best way to nudge your Dev team into fixing?

Thanks.

[Ann Worley]

It's true that the comment is 6 months old. It makes sense that you would be frustrated at being hit by that and other collaborative editing bugs.

The criteria we use to choose which bugs to fix is documented in our Bug Fixing Policy. If you need a new bug report opened, please use our support portal to open a support request so the support engineer can reproduce the issue and open a new Jira issue.

Atlassian Support is eager and happy to help verify bugs—we take pride in it! Create an issue in our support system, providing as much information as you can about how to replicate the problem you're experiencing. We'll replicate the bug to verify, then lodge the report for you. We'll also try to construct workarounds if possible.

[Stephen Kairys]

Thank you, Ann. Are you suggesting I open a new bug report for the COPY aspect of this issue? I have not seen evidence of it, but that does not mean there aren't corrupted pages out there I have yet to discover.

[Ann Worley]

I wasn't really suggesting that, rather letting you know that support requests are the avenue to opening bug reports. That said, if you are able to reproduce it I am sure the team would be interested, as these bugs with links are hard to replicate.