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; } } }

Page attachments changed to URL within our Confluence Space

Stephen Kairys_keaglp

Confluence Server 6.4.3:

Has anyone ever seen the following behavior?

Normally, when I bring up a document and click on an attachment, a simple filename appears on top. e.g.

VendorConfigOptions.PNG * [v.1 current]

However, without anyone changing the attachments, a large # of them now display their filename as follows (where documents.mycompany.com is our Wiki).

https://documents.mycompany.com/download/attachments/28213843/VendorConfigOptions.PNG%28Rev_20170525%29.png?version=1&modificationDate=1495715824613&api=v2

Based on spot checks, the problem may have started after we upgraded from 6.1.1. to 6.4.3. The only commonality I see is docs modified after the upgrade date, even if the image itself was not touched.

The ModificationDate (per Atlassian) is in Epoch Format. Based on three spot checks, this date matches the date on the Attachments page, within a minute.

While I see the images in my document now, if our Admins would change our root to (e.g.)

info.mycompany.com, I'm concerned the links would break.

Bottom line:

1. How could the above have occurred?

2. Can it be fixed?

Many thanks for any info you can provide.

Accepted answers

All comments

AnnWorley

Hi Stephen,

It sounds like you are running into behavior related to Images, attachments and user mentions in the page are broken after changing the BaseURL but before the base URL change. The bug report is public so you may comment or vote to elaborate on your case and be added to notifications.

Based on that bug, I am pretty sure if your admins changed the Base URL as you mentioned, that those attachment links would break. The workaround is to turn collaborative editing to off mode and back on, but since your pages are still displaying the images, I don't want to fix what isn't broken. Do you have a test instance you can try it on? I would like to spare your production instance if it isn't going to work because, as it says in the bug report:

The issue will stop occurring but you will need to go back and manually restore any pages that were affected
All existing shared drafts are lost when you switch collaborative editing off, so make sure your users have published any work they want to keep before you make the change.

I look forward to any follow up questions.

Thanks,

Ann

Stephen Kairys_keaglp

Hey Ann, thank you for your quick reply.

Before we go any further,

1. You said:
>>It sounds like you are running into behavior related to Images, attachments and user mentions in the page are broken after changing the BaseURL but before the base URL change<.

Please clarify the remark in bold.

********UPDATE********

2. I just found out we may have changed the Base URL (from http prefix to https prefix) around the time the problem occurred. Suppose that change occurred on 11/8/17. Would it make sense that if I modified a doc on 11/16/17, the bug would introduce these rogue filenames?

********UPDATE********

3. I just tried updating a page last modified in 2016. I added some text, and inserted a new image. But, when I checked an few attachments, the filename was still OK, without the URL. Am I not doing the right thing to recreate?

Thanks!

AnnWorley

Hey there Stephen,

I got that "before the base URL change" idea from the bug report:

"This is likely happening because Synchrony "saved" the links with the old Base URL, and then when the BaseURL changed, those changes aren't propagated into Synchrony (because it's saving the editor format)."

I think you did do the right thing to recreate the issue. If your team ever toggled Collaborative Editing off and back on since the base URL change, it would have fixed the issue going forward but any pages that already have the broken links still have them. That would explain your not being able to generate the URL-instead-of-filename issue even on older pages.

Is there anything that the pages with the attachment URLs instead of file names all have in common? Also, if possible, please find an affected page and restore it to an older version to see how long the attachment links have been URLs. (Use the ... menu on the top right of the page and go to Page History)

Thanks,

Ann

Stephen Kairys_keaglp

Ann,

1. Apologies. I was not clear in my question about "doing the right thing to recreate". I meant "was I not executing the appropriate steps". Here's my corrected paragraph:

>>I just tried updating a page last modified in 2016. I added some text, and inserted a new image. But, when I checked an few attachments, the filename was still OK, without the URL. Am I not following the appropriate steps to recreate<<

2. What do the pages have in common? Seems to be that they were modified at some point in November. Which may have been around the time we changed our Base URL.

3. Would any Confluence logs show;

a. When the Base URL changed?

b. If and when collaborative editing was turned off/on?

4. I will say that we found a page (last month) that did not exist until December and MAY, underline MAY have exhibited the issue.. I say that because an image copied from that page to a different Confluence instance showed the URL filename.

Thank you for your insight on this issue.

Stephen

Welcome!

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

Quick Links

Find more posts tagged with

confluence

attachment

bug