@Graham Gill: Atlassian support told me not to update links that point to "resumedraft.action" but to remove and recreate them. This is annoying, can take a long time to execute, but it seems to work. I confirm also we have that bug with the "unpublished changes" (and we do not use this new editor)

If you are consistently being impacted by this bug, I encourage you to migrate your instance to the new Fabric editor and rebuild once for all these pages using the Fabric anchors. This should permanently solve the issue for you!

Also we cannot move to the Fabric editor while there are regressions that would break some other parts of the page. This is currently our case and this situation is quite annoying...

If you are consistently being impacted by this bug, I encourage you to migrate your instance to the new Fabric editor and rebuild once for all these pages using the Fabric anchors. This should permanently solve the issue for you!

In case someone looks at this ticket and is misled, migrating to the new editor does not solve the problem. The new editor doesn't support dropping anchors at arbitrary places in the document - unlike many other wiki authoring applications, both proprietary and open-source. Instead anchors are currently only available on headers, what Atlassian has called "linkable headers". You can't link to cells in tables and you can't link to arbitrary places in a new editor authored document. For many users (see e.g. CONFCLOUD-69198 and CONFCLOUD-66773 for some entertaining reading) this is a huge problem.

But sticking with the legacy editor is also no good, because the present bug shows up on legacy editor authored pages seemingly at random, and doesn't go away or fix itself. To fix the problem, you have to manually re-edit every single link that goes to an anchor to make it work again, to stop opening the editor and instead go to where the link points. This can be a huge amount of work in a large and complex document. And it's not guaranteed. The next day the bug might come back, after all your manual fixes. I recently had Atlassian support re-enable page creation in the legacy editor (rather than just being able to edit existing legacy editor authored pages in the legacy editor), and after that, a legacy editor page I'd authored with plenty of internal links was hit by this bug. I don't know if re-enabling the legacy editor template is related or a coincidence, but this bug hasn't been solved.

UPDATE: I have a large doc, created with the legacy editor, with many internal links that I managed to revert to an earlier version without losing anything important. So now my internal links and anchors do the right thing. (Other legacy editor created large docs I have are way beyond reverting to get internal links working again instead of opening the editor.)

But if I open the page in the editor, and do nothing except close it again, I'm told there are Unpublished Changes. If I go back into the editor and view changes, I see that the internal links have all been converted to the "resumedraft.action" documented in this bug. So I discard changes and exit the editor.

I have a need to edit this document, but I guess that's just not going to happen. Which is stupid.

Hi everyone!

Just a quick update on this bug. After discussing with engineering, we are able to create anchor tags natively in Fabric without the Anchor Macro. The details for that are here: https://community.atlassian.com/t5/Confluence-articles/Fresh-full-width-and-colorful-new-features/ba-p/1191204

If you are consistently being impacted by this bug, I encourage you to migrate your instance to the new Fabric editor and rebuild once for all these pages using the Fabric anchors. This should permanently solve the issue for you!

Sunny

Hi everyone,

Thank you for the responses to our questions. We are still having trouble narrowing down the issue on TinyMCE, but we have some good news as to a permanent solution. This bug affecting the Anchor macro is only happening in the TinyMCE editor, and we have not anticipated any similar issues on the Fabric editor as it's built on new architecture. We will be rolling out Anchor support to the Fabric editor in the next few weeks, so I encourage you to add yourselves to this suggestion https://jira.atlassian.com/browse/CONFCLOUD-66773 to be informed when it's live. So the fix here is to convert your page to Fabric with the Anchor macro.

Thank you again for all of your feedback around this bug! I will be marking it closed for now.

Sunny

1) These are on already existing pages, so cant reproduce and a video isn't viable in this instance.

If a page as an anchor to go halfway down the page say for #mobiles (in the advanced link setup) it has been renamed to <pagename>#mobiles

ie."how to connect email#mobiles" - Here is a live example.

2) Please help us by answering these questions: 

• Does this issue happen to the same page/link repeatedly, or does it occur sporadically and with different pages/links?
  ALl the pages Ive seen it happen on (4 that Ive bothered checking) are currently fixed since I manually went through and amended the links and havent reverted, yet.
• Does your colleague experience the same issue when he accesses the link?
  Yes - if you click it as a user it tries to go to an edit page (we can complete this successfully as admins but suers get told they cant access this) my colleague whos an admin also sees the above text in the advanced text link when they go to edit the link
• Does this issue happen after you have cleared the cache to your browser?
  Yes
• Does this issue happen when you are accessing the page in in-cognito mode?
  Yes

Ah - cant post images.

Hi Sunny,

1. I have a video but cannot post it here due to the slightly confidential nature of the page's content... Can I send it to you elsewhere?

2.

• The issue occurs sporadically. I think that when one anchor link is affected on a page, all anchor links are affected. But I don't have the time to research every page
• The links are affected for everyone. The page itself has changed any everyone sees the same issue.
• Browser caching does not affect the issue. (The page has changed.)
• Incognito mode does not affect the issue. (The page has changed.)

When I say that the 'page has changed', I mean, imagine you paint a wall red. Someone comes along and paints it blue. It's blue for everyone. No matter how many times I close my eyes and open them again, the wall is still blue  If I put on sunglasses, it's still blue (although a slightly darker shade! That's where my analogy goes a bit wrong!)

Helen

Hi Sunny,

1) I have an example of the page with the issue. I assume you have access to it. 

https://quantifytechnology.atlassian.net/wiki/spaces/JPT328/pages/558923777/Protocol+-+FC+to+ACC

Links generated by the Contents macro are fine. The anchored links created manually have the issue. 

The contents links are of the type:

https://quantifytechnology.atlassian.net/wiki/spaces/JPT328/pages/558923777/Protocol+-+FC+to+ACC#Protocol-FCtoACC-0x00C0x00-Command-GetState

The manual anchored links are:

https://quantifytechnology.atlassian.net/wiki/pages/resumedraft.action?draftId=558923777#Protocol-FCtoACC-0x00C

2)

a) It occurs sporadically for us, we correct links and some stay corrected, others will revert after a few edits of the page.

b) All our users experience the issue with the same anchored links.

c) I've not yet checked,

d) I've not yet checked.

Hi all,

This is Sunny from the Confluence team. I really appreciate everyone's feedback on this bug. It sounds incredibly frustrating to have this issue show up on your documents, and we hear you that the workaround proposed is manual and doesn't always work. As Giuliano mentioned, we have spent the last few weeks working with a dedicated team for the full testing and reproduction of the issue in local environments. However, we have still not been able to reproduce the issue using the details from your reports and our local pages. Given the large number of reports and the severity of the problem, we would like to continue to work with you to figure out why this is happening. As such, I am asking for your help:

1) If you are continuing to experience this issue with a page, please provide a detailed video or reproduction steps along with the environment where you're experiencing this issue. 

2) Please help us by answering these questions: 

• Does this issue happen to the same page/link repeatedly, or does it occur sporadically and with different pages/links?
• Does your colleague experience the same issue when he accesses the link?
• Does this issue happen after you have cleared the cache to your browser?
• Does this issue happen when you are accessing the page in in-cognito mode?

Thank you for your continued patience around this and I hope that we can get to the bottom of this issue together!

Sunny

Hello Everyone,

For all the watchers and affected customers, we want to thank you for taking the time to come and share the impact caused by the issue. Due to these comments and additional support cases being created with the confirmation that even after the workaround, the same behavior is persisting, we are re-opening this report to reflect the current status of the investigation.

At this point, we are working with a dedicated team for the full testing and reproduction of the issue in local environments so we can make sure of pursuing and applying the fix at a code level. Although we are working with the tests, we encourage you to continue posting new updates in regards to the impact and any information that you feel that is valid to be shared.

Thank you again for understanding this scenario and bringing such information so we can improve the customer experience when working with this and any other macros from the application. As soon as we have a new update, we will share it and update the status of the issue accordingly.

Wish You the Best,
Giuliano de Campos
Atlassian Team