Adding images per drag&drop or from clipboard in CKEditor fails

[surli]

Thanks, I’ll try to check a bit more with your options. Can you confirm the following:

1. The image appears properly in the editor after the drag&drop
2. You’re getting same behaviour with the in-place editor (when you click on edit and it shows the editor immediately without loading a page) and in the standard WYSIWYG editor (displayed when you create a new page)
3. When you save, the attachment is properly added, it’s just the src of the image which is wrong

Can you try disabling the new temporary attachment feature by performing the following: you go in Administration > Editing > WYSIWYG Editor, and in Advanced configuration you put:
config['xwiki-upload'].isTemporaryAttachmentSupported = false;

Then try again to drag&drop a picture in a page (maybe perform a force reload of the editor to be sure the config is taken into account). Let me know if it’s working better or not.

[jmiba]

@surli

Can you confirm the following:

1. The image appears properly in the editor after the drag&drop
2. You’re getting same behaviour with the in-place editor (when you click on edit and it shows the editor immediately without loading a page) and in the standard WYSIWYG editor (displayed when you create a new page)
3. When you save, the attachment is properly added, it’s just the src of the image which is wrong

I can confirm this.

As to your suggestion: Disabling the temporary attachment feature does not fix the problem.

[brickhead92]

@surli

Can you try disabling the new temporary attachment feature by performing the following: you go in Administration > Editing > WYSIWYG Editor, and in Advanced configuration you put:
config['xwiki-upload'].isTemporaryAttachmentSupported = false;

I’ve found the same issue after updating to 14.4.1. the change above resolved the issue for me.

Using Tomcat9, Short URLS with URL re-write as per Short URLs.

[surli]

We do have an open issue about the upload of attachment with short URL, you can check it here: [XWIKI-19444] Uploading an attachment fails when using short URLs - XWiki.org JIRA

[jmiba]

@surli

Can you try disabling the new temporary attachment feature by performing the following: you go in Administration > Editing > WYSIWYG Editor, and in Advanced configuration you put:
config['xwiki-upload'].isTemporaryAttachmentSupported = false;

I can confirm this now, too.For this to work, I have to re-enable the plugin wiki-upload again, which I had disabled because it causes an upload error ckeditor.upload.error.emptyreturn.
So my setup is now:

• wiki-upload => enabled
• config[‘xwiki-upload’].isTemporaryAttachmentSupported = false;

This solves the problem for now.

[surli]

@jmiba

I can confirm this now, too.For this to work, I have to re-enable the plugin wiki-upload again, which I had disabled because it causes an upload error ckeditor.upload.error.emptyreturn.

Is your wiki also configured to use short URLs?

[jmiba]

@jmiba

the installation is behind a reverse proxy without url rewriting ( Apache: RewriteRule ^/ikmz/xwiki/(.*) ajp://xwiki-ikmz.b-tu.de:8009/ikmz/xwiki/$1 [NC,P]

No, we don’t use short URLs, as far as I know (see quote)

[surli]

@jmiba could you tell me if the problem you had were related to the upload of attachment on a translated page?

[jmiba]

No, the problem occurs or occured with untranslated pages.

[jmiba]

Hi @surli, since the upgrade to 14.9 we have had no problems any longer uploading images via drag and drop, even if the configuration option in WYSIWYG “config[‘xwiki-upload’].isTemporaryAttachmentSupported = false;” is disabled.

But further exploration has shown that there is a problem with multilanguage support and the new image editor xwiki-image. Image editing only works correctly in monolingual wikis with English as defalult language. When I switch to mulitilingual and define another language as default (e.g. German), inserting images via the image edit dialog results in broken source links in view mode. (Dragging and dropping images in the editor works, though, even on translated pages.)

[mleduc]

@jmiba

But further exploration has shown that there is a problem with multilanguage support and the new image editor xwiki-image. Image editing only works correctly in monolingual wikis with English as defalult language. When I switch to mulitilingual and define another language as default (e.g. German), inserting images via the image edit dialog results in broken source links in view mode. (Dragging and dropping images in the editor works, though, even on translated pages.)

Hello @jmiba,

I followed what you describe, and noticed that images upload during the creation of non-english pages produce images with a bad name (i.e., __fileCreatedFromDataURI__.png).
Is it what you experienced as well?

PS: See Loading...

[Wardenburg]

Is the drag and drop issue perhaps similiar to the copy paste functionality (of the snippert tool)?
Because I noticed that the name of the file changes between whats put into WYSIWYG and whats uploaded as an attachment, see [XWIKI-20308] Copy pasting from snip & sketch (windows) breaks image link - XWiki.org JIRA

[jmiba]

Hi @mleduc,

No, that is not what happens. The uploaded image file is correctly attached to the page using the correct file name (or a generated one if the image editor is not used and the image is uploaded by drag & drop or pasted from the clipboard). Rather, the file path that is written is bad. In source code an image added via the image editor in a non-English page looks like that:

<img src="/xwiki/wiki/testwiki/download/Sandbox/TestPage3/attach%3Ainnovation.jpg" data-xwiki-image-style-text-wrap="true" id="Iattach:innovation.jpg" class="wikigeneratedid" alt="attach:innovation.jpg">

when it should look like that

<img src="/xwiki/wiki/testwiki/download/Sandbox/TestPage3/innovation.jpg" data-xwiki-image-style-text-wrap="true" id="Iattach:innovation.jpg" class="wikigeneratedid" alt="attach:innovation.jpg">.

On English pages the image path is written correctly, without the additional attach%3A.

[mleduc]

Thanks @jmiba. May I ask you to create an issue on jira.xwiki.org with as much information as you can?
I couldn’t reproduce your issue for now but having it documented in Jira will greatly increase the chances that I (or somebody else) work on fixing it.

[jmiba]

@mleduc have done so: XWIKI-20351

[mleduc]

We closed Loading... as cannot reproduce. Please let us know if you still experience the problem.

[FlorianHahner]

The Problem still exist in 14.10.2 / Language Setting: German

I insert an image from clipboard with CTRL+V and for a part of a second you see the correct image after that the WYSIWYG Editor overwrite the image .

In the nginx logs i see everytime the filename “fileCreatedFromDataURI.png”.

In xwiki 13.X Version i had this problems only in firefox. Chrome or Edge worked as a charm. Now this Problems occurs on all browsers.

In the browser DEV console this message appears:
[CKEDITOR] Error code: clipboard-image-handling-disabled.
[CKEDITOR] For more information about this error go to Error Code Reference - CKEditor 4 Documentation

[Matthias]

Not sure if this is the same issue, but I have teh problem that any newly pasted image overwrites the first one. before saving the page the editor shows the older image, after saving all pasted files show the last pasted one.
Found an older discussion where it was only happening with FF Paste second image via clipboard overwrite first image - Help / Discuss - XWiki Forum, but for me it happens with any browser.

[mflorea]

@FlorianHahner

In the nginx logs i see everytime the filename “fileCreatedFromDataURI.png”.

This is probably Loading... which has been fixed in 14.10.4 .

[mleduc]

Hello,

I think I finally found out the missing criteria to reproduce. Can you confirm that the page where you encountered the issue has a xwiki/2.0 syntax?

If that’s the case, the issue has been fixed (Loading...) and will be available in XWiki 14.10.5 and 15.1RC1.