nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Converting from Legacy Editor - Images changing to "Unknown Attachment" intermittantly

Fraser Shepherd

We've started converting our Confluence pages from the Legacy Editor to the new editor, we've noticed some weird behaviour on some of our pages.

On conversion, in-line/pasted images are changing to "Unknown Attachment", but not all the time or for every document, and not even all the time for the SAME document.

As an example :

Page A has 5 in-line images pasted in at various points in the document. These are pasted in as plain images, no third party apps or macros or anything that could cause compatibility issues. Page A was created with the Legacy Editor, has 10 total Historic Versions, and when we hit "Edit" we are prompted to convert to the page away from the Legacy Editor.

On hitting "Convert Page" the in line images all change to "Unknown Attachment" and do not display any more.

Now the weirdness.

I revert back to Version 10, the last version before conversion, and the images reappear. I then hit Edit AGAIN, allow the conversion to take place, and THIS time the images are retained.

This doesn't always work on the first try, or the second, but it does always EVENTUALLY work. We've not found a page yet where "trying again a few times" doesn't work. But we don't want to tell our users to "just keep trying till it works" for converting hundreds of pages, and this would remove any automation we might want to put in place for this conversion, as every page will need to be manually checked to ensure this issue has not occurred.

Any idea what could be going on here? Is this a known bug/issue I'm overlooking?

Accepted answers

All comments

Alex Koxaras -Relational-

Hi @Fraser Shepherd and welcome to the community,

Strange behavior, to say the least. Can you try copying the page and convert it again, and see if the problem persists? If the problem persists, can you check the page storage for anything suspicious? Another idea would be to export the page and try to import it again. Finally, if you are on a paid plan, raise a request to Atlassian's support.

Let me know if any of the above helps.

Fraser Shepherd

Hi,

Got a request open at the moment, just figured I'd ask the community while waiting in case there was some known nuance/issue I was unaware of.

I will try the above for a few pages, but again even if this does work I really don't fancy doing that for every page we need to convert

Thanks

Alex Koxaras -Relational-

Sure thing! Try it just for a couple of pages. If you have many pages of that type then it depends on what the problem is. E.g. if the problem would be located to a special character on each image, then you could use python to find these pages and then replace that character on their storage. That would solve the problem. Another option would be to have Atlassian do that (if applicable)

Fraser Shepherd

I don't see anything particularly egregious in the code for the image when viewing storage :

<ac:image ac:align="left" ac:layout="align-start" ac:original-height="222" ac:original-width="795" ac:custom-width="true" ac:width="795"><ri:attachment ri:filename="image2023-8-4_13-53-36.png" ri:version-at-save="1" /></ac:image>

Joseph L Whited

Not sure if this is the same issue, but I had a similar problem when using api to post content to confluence from a script. Here's the write up we made about it:

Reproducible cause: pages created via the REST API in storage format are treated as legacy content unless you explicitly set the "editor" content property to v2.
Opening such a page in the Cloud editor converts it, and that conversion rewrites every attachment reference to UNKNOWN_ATTACHMENT - images and attached PDFs stop rendering.

Matched-pair test on Confluence Cloud, two pages created by the same script, identical body and identical two image attachments.
The only difference was the editor property.

- Page A - no editor property, which is the default for REST-created pages. Opened in the editor, the images immediately displayed as broken. The stored body was still intact at that point, so merely opening the editor does no permanent damage. On save, both refs were written to storage as ri:filename="UNKNOWN_ATTACHMENT", permanently.
- Page B - POST /rest/api/content/<id>/property with {"key":"editor","value":"v2"} right after creation. Same edit and same save, both refs intact, and the storage format was not rewritten.

Two details that cost us time:

- Passing metadata.properties.editor in the CREATE payload is silently ignored. The property reads back 404 afterwards. It has to be POSTed to /content/<id>/property as a separate call.
- The published Atlassian KB for "Unknown Attachment" attributes it to cross-page refs from copy/pasting images between pages. That is a different cause. Our affected pages had zero <ri:page> refs, and the refs were plain ri:filename on the same page.

Retrofitting the property onto existing pages is non-destructive.
It adds a property, does not change content, and creates no new version.
That protects pages already published by a script before anyone opens one in the editor.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

cloud

confluence-cloud