Hi everyone, below is new official Jira/Atlassian thread on this paste image topic from Daniel Gutierrez (who works in the Atlassian founders office and set this up).  Let's all try to rally around this new official thread and vote to get this issue fixed once and for all:

Thanks for your interest in this use-case! I've opened a feature request on jira.atlassian.com for you watch and vote on: JRACLOUD-71695

I'm also locking this particular thread for comments as it is dated and we want to make sure your comments and feedback get the attention they deserve. Please create a new question on Community if you need help with a particular aspect of Jira's current behavior. And if JRACLOUD-71695 completely captures what you're looking for, please watch it to keep up with any changes planned in Jira.

Thanks!

Daniel | Atlassian Support

patrijst There wasn't so i created this ticket for you to vote on https://jira.atlassian.com/browse/CONF-43522.
Feel free to explain your use case for having confluence upload the image instead of referencing the source. Thanks!

Thanks, is there an issue I can vote for that would upload copied web images?

patrijst This issue was addressed for copying images within the same confluence instance. When you paste across instances, that will be the same behaviour as if it was a web image link because thats what it is.

This doesn't seem fixed.. pasting Confluence content from one instance (different) to another (5.10 to 5.9) will add the images as a referal to the other instance instead of upoading it as new images.

Today i run into this problem. Hope this will fixed in the near future.

Hi guys!

I am not an IT expert, hence I do have some queries regarding the busted stuff report:
I have now downloaded python 2.7.3 - but I have no clue how to run the busted stuff report. is there a documentation somewhere around where I can read what needs to be done step-by-step?

thanks a lot!

christian

Hi Sarah,

Thanks for the tip, especially about using the Source Editor plugin. I have been annoyed by the problems that can occur when you copy a page containing images, when those images are actually attached to, well, who knows where?

Now that Confluence is moving/has moved to the Rich Text editor and XML I think I'll be using the Source Editor plugin more often. In other words, the more confluence makes things easier for some users, it's nice to have a way to easily look under the hood when we want to.

Robie

Hallo Christian

In answer to your question about identifying affected pages: You can use the "Busted Stuff Report" created by Ed Dawson:

• http://blogs.atlassian.com/2011/12/scanning-confluence-for-content-errors/
• https://bitbucket.org/edawson/busted-stuff-report

To prevent the problem from recurring, you can use the Source Editor plugin. It pops up a source window in the editor that shows the XML source (storage format) of the page. If you copy the storage format rather than the rich text, all your images will remain relative. So will your links – this may be important to you too.
https://marketplace.atlassian.com/plugins/com.atlassian.confluence.plugins.editor.confluence-source-editor

If you and all editors have admin rights on your Confluence site, you can do that without the Source Editor plugin. Admins can see a "View Storage Format" option in the "Tools" menu.

You'll still need to re-attach all your images to the new page. But at least they won't be misleadingly there and referring back to the original page.

Cheers
Sarah

Is there a way to identify the affected pages?

We are also running into this problem. We are currently "migrating" all our SAP documents from Word into Confluence. So we import a page (into a space called "test area" and then copy/paste content from the imported page (in edit mode) to a new page in space "system documentation" (in edit mode). (we do copy the content because we will not use all the information from the word file)
Everything looks fine and all images are visible in the page in "system documentation". From time to time we remove all pages from the test area and whoop all images are shown as broken link.
It took some time for us to find out the reason.

Would be a fabulous feature if the embedded images would also be copied to the new page when copying the content.

still affects 4.3 (tested on 4.3-RC1)

Updated description to reflect all the discussion on this ticket.

As a tech writer for NASA I would like add strong support to the perspective that Sarah expressed on 18/Nov/11. Here's another scenario: Page A and Page B have been developed independently as drafts and have lots of images. Now we want Page C to be a concatenation of Page A and Page B. Wouldn't it be nice to copy and paste Page A and Page B into Page C and have the images automatically attached Page C? That way we can delete the drafts without the images disappearing on Page C.

We have several people preparing these drafts as sections for a major User's Guide, so it would really help our project if this capability were implemented.

By the way, I noticed on another page that Sarah is listed as an Atlassian Technical Writer. I hope everybody at Atlassian pays attention to what she says.

As one of the people on the extranet, I definitely agree with the unanimous conclusion reached by Sarah, Chris, and John. The functionality they described is much more intuitive and would contribute greatly to a better user experience in confluence.

Discussed this use case with Sarah, Chris and John. Everyone agreed that the ideal way this would work is to attach the images to the page when pasting. That would always ensure that the image is available when viewing the page. This is blocker for upgrading to DAC.

I totally agree with Sarah and confirm each and every use-case she described as a common practise.

I'm not so sure that this bug is a characteristic of the way technical writers use Confluence. I think it is more global than that. I have seen a number of people on our extranet running afoul of this problem. A very typical scenario is when drafting a blog post. People draft the post on a page, then copy the content to a blog post and attach the images to the blog post. However, the content ignores the attached images and draws the image from the original page. It is impossible to see this fact in the editor itself, as there is no way of seeing where the image comes from or even what the image name is.

The person then typically deletes the draft page. In some cases, they leave the draft page there but it has restricted viewing (since it is a draft). The result is that other people cannot see the imagesl

As far as I'm aware this issue has nothing to do with CPSP-45.

Just discovered a workaround for this issue...

First, some background

In Confluence 4.0, when you insert an image on a page (which is attached to that page), Confluence will store this image reference 'relatively' using the following XHTML markup:

<ac:image>
    <ri:attachment ri:filename="apples.png" />
</ac:image>

When you copy the source of 'Original Page' and paste it into a new page called 'Target Page' (for example), these image references will become 'absolute' and reference the images attached 'Original Page', such that these image references in 'Target Page's XHTML markup become:

<ac:image>
    <ri:attachment ri:filename="apples.png">
        <ri:page ri:content-title="Original Page"/>
    </ri:attachment>
</ac:image>

If, however, you were to use Confluence's 'Copy Page' feature, to copy 'Original Page' to 'Copy of Original Page', these image references will remain 'relative' (presumably because the images that were attached to 'Original Page' are also copied and attached to 'Copy of Original Page'). Hence, the image references in 'Copy of Original Page's XHTML markup will remain relative:

<ac:image>
    <ri:attachment ri:filename="apples.png" />
</ac:image>

So, what's the T/W workaround for handling image references on a page you want to update?

Use the following procedure:
This is effectively the same as the procedure described above (in the 'Description' section) with the exception of the 1st step.

1. Assuming you want to update Page A, 'Add' a new page to the page to Page A (e.g. entitled Page A - draft) and use Confluence's 'View Source' feature to copy the source from Page A to Page A - draft (using the usual Ctrl-A / Ctrl-C / Ctrl-P keyboard shortcut combinations on Windows OSs)
   Existing image references in Page A - draft will be converted to 'absolute' references (described above) and reference the images attached to Page A.
   
   
2. Update content on a page Page A - draft (with viewing restrictions).
   If you need to add new images to Page A - draft, add them to Page A and using the 'insert image dialog box' on Page A - draft, insert the images from Page A.
   
   
3. Update the content on Page A (by copying the updated source content on Page A - draft over Page A and then saving Page A).
   
   
4. Delete the hidden Page A - draft, which is no longer required.
   Since the image references on Page A - draft referenced images on Page A, Confluence 4.0 will convert the 'absolute' image references back to 'relative' image references by removing the ri:page elements from the image references.

Thanks for coming up with the solutions Paul. I don't have an opinion one way or the other as to which one you should choose, but fixing this would really help us with our current T/W workflow/processes.

As Chris and Sherif currently seem to agree with me that the behaviour you are requesting is not the 'normal' case I've been thinking a little about alternative solutions.

Just out of curiosity, is this something that customers have been requesting?

I would have expected (and would also argue) that the 'normal' behaviour for copying and pasting 'source' content should be that image references in the source content should not change when it's pasted into a new page — i.e. if you don't have those images attached to the new page, those image references will be broken (as expected). This was the behaviour in Confluence 3.5, so why has Confluence 4.0 introduced new (and unexpected) behaviour.

The editing experience is now especially frustrating as you can no longer edit references to images on a page in Confluence 4.0. Please reintroduce this capability!

This issue is compounded by the fact that there's no way of seeing which image is which. The process of updating images on a page is very time-consuming and frustrating. I guess, if Confluence is aimed at one-time publishing such as blogs and pages that contain temporarily-relevant information, or information that will never need to be updated again, then this level of obfuscation is OK. But if it's aimed at technical documentation, intranet policies or anything where the author needs control over the content, then it's not.

As Chris and Sherif currently seem to agree with me that the behaviour you are requesting is not the 'normal' case I've been thinking a little about alternative solutions.

One fairly easy fix would be to write a plugin operated from the 'tools' menu which checks the page and changes any embedded images to point to matching images found on the page, instead of pointing to the source images. This would be about 1 day's work.

Alternatively, it should be possible to write a TinyMCE plugin to do this automatically on paste within documentation spaces. I'm not as familiar with this area but I think it would be 2 - 3 days of effort. (The tricky part being to give the Javascript visibility of the page attachments.) Might be better to write a plugin that does the rewriting on createPage/editPage events.

It looks like this issue relates to CONFDEV-4509, which means even more reason to fix the issue.

Incidentally, I've marked this as a 'critical' because after performing step 3 of the procedure above, we need to edit the original page again and fix every single image (by deleting the image and re-adding it to the page).

Giles' feedback on Paul's response:

The use case we are trying to cope with is when someone wants to create a page based on some existing page. They might well copy the Editor (or View Source) content and paste it into a new page. Any images they copy and paste will be broken if we don't keep them pointing to the original place the images are hosted.

Hmmm - I can see the advantage of this feature, but has there actually been much customer demand for this behaviour?

• What if someone wants to update an image on the original page without wanting it to change on the copied page?
• How would a customer know that the image on the copied page is actually referencing the image attached to the original?

The tech writers use Confluence as a documentation site and as such, we need to publish page updates (i.e. a fundamental part of the doc update process). The only way I see that we can do this in Confluence is using the steps I described in the 'Description' above. Is there a better way that we can do this in Confluence? If so, please let us know

1) Could you (tech writers) start using 'Copy Page' to copy the draft back to the original? This would provide you with the additional benefit of not needing to manually attach any new images to the original document.

How would we do this? ... especially when you consider the following with respect to our documentation on CAC:

• Customers often contribute useful comments to our pages. If we used the 'Copy Page' feature, wouldn't this just create a new page (and we'd lose all those comments)? What would we do with the original page that contains the important comments? Delete it?
• Wouldn't solely relying on the 'Copy Page' feature also remove the original page's 'Page History'? 'Page Histories' are very important - we use them similarly to how developers use 'change histories' in VCSs.

2) We could render to the Editor relative image references. To support the previous behaviour we keep 'View Source' rendering with absolute image references. It would not be obvious to an inexperienced user that they need to use 'View Source' if they are doing a 'copy and paste'.

Wouldn't lots of people who've used Confluence in the past be familiar with this behaviour - and would expect that behaviour to be maintained this way? Aren't we compromising Confluence's publication capabilities (and flexibility) for the sake of inexperienced users here?

Having said that, if there is a better method by which the tech writers can use Confluence 4.0 to publish page updates and maintain page comments (than the one described above, which the T/W's have been doing on CAC for a while now), then please let us know!

FYI ... Whenever we've needed to add and display new images on a draft page, we've always attached them to the original page (and on the draft page, referenced those images attached the original). (This isn't a particularly difficult concept to grasp for people who use Confluence to publish documentation.) I guess the only disadvantage with this approach is that the public could see those new images before the main content is updated. However, that's always been a minor issue.

Response from Paul C:

The Copy Page operation is actually working correctly and is refactoring embedded images when it copies (well it actually ensures that the reference is relative).

The problem you have is that when we render to the Editor, the Editor representation does reference the image container directly. There is a reason for this.

The use case we are trying to cope with is when someone wants to create a page based on some existing page. They might well copy the Editor (or View Source) content and paste it into a new page. Any images they copy and paste will be broken if we don't keep them pointing to the original place the images are hosted.

You have a "special" case going on where you happen to know (or will manually ensure) that all of the images on one page are also present on another.

So I'll need to gather opinion on whether we should make this change - it would be counter-intuitive in a lot of cases. Some possible solutions -

1) Could you (tech writers) start using 'Copy Page' to copy the draft back to the original? This would provide you with the additional benefit of not needing to manually attach any new images to the original document.
2) We could render to the Editor relative image references. To support the previous behaviour we keep 'View Source' rendering with absolute image references. It would not be obvious to an inexperienced user that they need to use 'View Source' if they are doing a 'copy and paste'.