@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!

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

Also experiencing the same issue.

Achors Links have suddenly changed to include the title page and now for some reason take you to an edit page.

Ive got at least 2 pages with 15 anchors and god knows how many more.

Please outline what was changed and make a reversal of it to fix the issue.

Hi Rahul,

We use also advanced links with # followed by anchor or heading as described here: https://confluence.atlassian.com/confcloud/insert-links-and-anchors-724764900.html

and this worked for years. I've also noticed links to the same page, i.e. #anchor or #heading, are replaced by pagename#anchor, not only in the link but also in the displayed text. Sometimes displayed text are replaced by a page number which seems to be the draft, an nonexistent draft. Saying this is not bug is not acceptable. As I said 2 days ago, I updated only one word in a page where I already corrected all the bugged links. Changing one word in that page has broken all links that point to the same page.

Hey Rahul,

could you please download my Video I´ve postet last time? Watch closely - this is how I´ve done it all the time. I´ve allways copyed the Name of the Anchor and put a "#" in front of it - most of the anchors are for the same page. These anchors were broken as well.

So: Sorry. It´s not an End-User problem. Its an documantation bug or a program bug.

My offer: Write me how to do it correctly. As soon as I have some spare time I´ll test it.

I second the "not an end user error" assertion by Oliver. Many of our links are anchor links to anchors on the same page, so we create them by using the simple #anchorname syntax. No copy and paste or dealing with URL encoded characters at all. Were this truly a user error, our links would never have worked at all.

Frankly I'm surprised there's not a huge uproar about this "not a bug" resolution. This is quite obviously a bug that has affected a number of users. It's detrimental enough that our management team is evaluating Confluence alternatives and planning to move our entire company to a different system.

Hi Rahul,

Thank you for your investigation but my team only create anchored links using the correct way in the atlassian support document and still experience the bug.
Working anchors which were working one day stopped working. This is not an end user error.

Kind regards,
Oliver

Folks,

    I believe I found the issue and i could reproduce the problem too.

This is not a bug as per me but a user education on how to correctly link to anchor. I am giving these observations based on the fix I provided to my organization users but I suspect the same problem exists for every cloud user reporting this as bug.

I found the users create anchor link by copying the page name from the page url from browser.

Say page on which the anchor exist is having URL such as following:

https://xxxxxx.atlassian.net/wiki/spaces/JIRA/pages/1136951483/Broken+Link+Demo+Test

Then another pages (or same page) where the link to anchor is (generally) created using following:

Broken+Link+Demo+Test#TestAnchor

If you later click that anchor url, you are redirected to create page.

However, as per user guide from Atlassian (https://confluence.atlassian.com/confcloud/insert-links-and-anchors-724764900.html), you should create link to anchor as follows:

Broken Link Demo Test#TestAnchor

Please observe the missing '+' signs from the link which represent the spaces in the page name. 

I have to say that the functionality in confluence to create link to anchor is not so user friendly and hence users end up having to copy page name from the browser URL and forget to remove all those '+' characters. Ideally there should have been a way to search for a page anchor in advance mode to create link.

Hi Kuldeep,

I just reopened case PSCLOUD-20534. I edited a page 1 hour ago where I had this problem already. I corrected the broken links on May 16th. Today I just changed one word in this page and links, located somewhere else in the page are again broken. Thanks to reopen the CONFCLOUD-65853 bug.

Hello Everyone

Thank you for being patient as we are working on this issue. We have been chasing this bug and we have not been able to reproduce this issue. This ticket is marked as not a bug as the original issue which updated page ids to draft ids is no longer happening. We are aware that there are some customer instances with existing broken links. We are working to find a solution to fix those broken links in existing pages. If you have a few broken links, feel free to use the workaround. If the broken links reappear after using the workaround, please open a support ticket and provide steps to reproduce. This will help the cloud support team to verify and reproduce the issue.

Thank again for your patience

Hello,

I have provided the workaround to someone from my team and it worked for the first day BUT the same issue is happening with the anchor links again where it takes you into edit mode. Please review and advise.

Regards,

Sean

Hi, can you please explain us why this bug is resolved as "not a bug". Does this mean this is a feature ? I still have problems and updating the pages to correct the links manually can work (workaround proposed) until I edit the page again breaking the links once more... Thanks

Hey Oliver,

I can understand you very well. It was the same here. From one to a nother Day some (not all) anchors in different documents where distroyed... I fixed every page by myself.

I actually have some trust issues as well. We just found out how to use anchors - so not all of our documents use them. Now that I know how to use them I wanted to change all the old pages - but now I don´t know if I should do that.

The document I fixed is a big one at the moment, but it will be smal in future - we want to put all of our handbooks into this system...

The Index anchors seem to work. Maby I will not place manual anchors in the future... - strange "feature".

Hi Björn,

I have hundreds of these anchored links all over the place and don't have the time to go and correct them manually.

I am very disappointed that Atlassian has not corrected the links for our company, seeing as one day they worked, then the next they were broken without intervention by my team.

I no longer trust the tool for our documentation.

Best,
Oliver

Hello Oliver,

Hello @all,

to be fair- I tryed it todayas you can see here: https://www.file-upload.net/download-13688545/Bearbeiten-InstallationClientundServer-RATIOWiki-GoogleChrome2019-08-1308-16-54.mp4.html  it seems to work... (Sorry - it tooked my 30 Minutes to redo and check all of them.)

I had a lot of broken anchors, but this time they stayed correct after I changed other anchors. I will add some new content later and I will record this as well. Maby it will work this time. (I really don´t want to put a nother 30 Minutes in this - I did this a lot of times :-/ )

Yours Björn

I see this has been marked as not a bug. Does that mean this utter frustration is a feature?

I've encountered this problem as recently as yesterday evening. I do not think it has been resolved.

Hello Kuldeep,

this Work-Around is the thing we do all the time - BUT: If I do as you say and I want to check them after - lets say 10 anchors - its possible to destroy a nother one... On my page it´s a horror to do that:

The problem is that I have e.g. 10 different kind of installation routines - in one we need this, in a nother one we have this options...

So several anchors to one topic - then several anchors to a nother...

Example:

Installation Type 1: Anchor 1, anchor 2, anchor 4

Installation Type 2: Anchor 2, anchor 4

Installation Type 3: Anchor 1, 2, 3, 4 and so on....

So I check Installation Type 1 and publish it to test every anchor. Then Installation Type 2 and publish it.... In this situation I have to test Installation Type A AGAIN and sometimes one or two anchors do not work anymore so I have to do it again....

I hope you understand my problem - even with my bad english here ^^

Yours Björn

Hello @all,

we have the same problem here. As soon as I add a link (external), add a new anchor or sometimes even only change a bit of the text WITHOUT anchors or links changed or added I also have the problem that sometimes all links / anchors won´t work anymore... Some times only some of them won´t work...

Even when I change ALL of them AGAIN: Some times it works, some times not...

It seems to me, that the anchors seems to change itself so you can open them from external. This is fine - but inside they wont work anymore so you always open a new page. Even the Name changes itself here:

#Anchor for Index

Index

Bla bla #Anchor for Index

Sometimes it changes itself to:

#Anchor for Index

Index

Bla bla #Pagename Anchor for Index

Do you get these results aswell?

Hello Everyone,

As a public update for our progress, we are still working on this issue and at this point of the investigation, we can confirm that the page identifiers being referred by anchor links are incorrectly updated to draft id's instead of content id's, which is the root cause for having the links breaking / pointing to a draft.

While we are still doing our best to mitigate the root cause for this one, the suggested workaround will be to update the affected links as it will point to the correct identifier. At this point, we do not know what caused these links to be updated to incorrect page identifiers as we were not able to reliably reproduce this scenario.

We'll make sure to keep you updated as we work towards resolving this issue.

Thank you very much for all your patience so far,

Avinoam

Another month has passed with no solution or workaround in sight, I have tweeted the CEO expressing my disappointment. 

Agreed with the above. I have seen this countless times though and I have given up hope of anything ever being fixed. If it was up to me, I'd have walked away from Confluence about three years ago  

This has happened to me not once, but twice on a huge page with hundreds of links. I had to manually fix every one of them, and then yesterday when I opened the page, they were all broken again.

This needs to stop.

Hi all,

Apologies for the inconvenience this issue has been causing! We've prioritized this issue on our end and we'll make sure to communicate once the team has a fix in place.

Thanks!

The turn around of this fix is approaching 3 months. For a high priority bug this is poor performance by Atlassian. 

Hi, I just had this problem once again and found something that could help you:

• When editing this page I received a warning telling me a problem occurred and I had to refresh the page (this occurs very often ) then I pressed F5, edited my page and saved: all my links were corrupted.
• I did then revert to previous version and edited again: this time no error message was displayed and saving the page after my edit did not corrupt the links.

Edit: just edited another page where links were OK at display but now all are bugged when editing... Have you got news on when this will be fixed?

This is a big problem for me...

I create a link to an anchor or heading on the page: #anchororheadingname. This works...

At some point, the page name is added to the link in the editor: PageName#anchororheadingname. I guess the link now looks for a different page within the same site with that anchor. It can't find it, hence the link in read mode is updated to: "...resumedraft.action?draftId=..."

I thought I'd add this information as it's not explicitly mentioned here.

This has a massive impact. I have broken links EVERYWHERE in my public-facing documentation. (Along with long-standing issues with broken links that I don't believe will ever be fixed, it's embarrassing for us and annoying for our customers.)

Please, please fix.

FYI - this is hindering a CommOps operation with thousands of stakeholders and is debilitating to our business needs. Please prioritize this ASAP. 

Thanks Klaus, I have to update several pages manually to correct those links very often... Hope you'll find the problem.

Hello,

we'll pick up this bug in the next sprint starting next week. I'll update the ticket once we have a better grasp on how long it takes to fix this.

Is there an ETA for this to be fixed? 

I am still experiencing this issue. I do not want to have to go through every link and rebuild it manually. This was broken by Atlassian backend, the backend should resolve it for me.

Hi,

From what I've seen: links to anchors, headings and page#heading are affected, links to pages are not. When updating a link a in page, this can damage other links in the page that point then to something like "...resumedraft.action?draftId=...". The only workaround found at the moment is to rebuild the damaged links manually. Once updated, new updates on the pages do not seem to damage them anymore.