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

[jmiba]

Since update to V. 14.4, when images are inserted in edit mode via drag & drop or from the clipboard, they are uploaded as attachments but are no longer displayed after the page is saved. The reason is an incorrect URL to the image source: the entire path is appended to the path in URL-coded form, which leads to the error.

Example: The path for an image added via drag&drop is

• src="/ikmz/xwiki/bin/download/Fehler-Datenbank/Bild-Fehler/WebHome/%2Fikmz%2Fxwiki%2Fbin%2Fdownload%2FFehler-Datenbank%2FBild-Fehler%2FWebHome%2Fimage-20220616084930-1.png?width=1920&height=1080"

when it shoud be

• src="/ikmz/xwiki/bin/download/Fehler-Datenbank/Bild-Fehler/WebHome/image-20220616084930-1.png?width=1920&height=1080"

Uploading or adding images using the image dialogue works fine, however.

Emptying browser caches doesn’t fix the problem. Has anyone experienced the same problem? What are we doing wrong?

[surli]

Hi, we changed the way the attachments are uploaded since 14.4 (see https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/14.3RC1/#HMiscellaneous).
Now I never reproduced such problem, could you give some more details about your configuration: which servlet engine are you using? Do you use a specific URL configuration? Are you using XWiki behind a proxy that could rewrite URLs?

[mflorea]

Could you open the Network tab from the browser’s developer tools and filter by “FileUploader”. Then drop a file and check the JSON response. Is the value of the url field right?

[jmiba]

@mflorea The json response is this:

• {“uploaded”:1,“fileName”:“image-20220616103935-1.jpeg”,“url”:"/ikmz/xwiki/bin/download/Fehler-Datenbank/Bild-Fehler/WebHome/image-20220616103935-1.jpeg",“resourceReference”:{“type”:“attach”,“reference”:“image-20220616103935-1.jpeg”}}

Seems right to me

[jmiba]

@surli

Hi, we changed the way the attachments are uploaded since 14.4 (see https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/14.3RC1/#HMiscellaneous).
Now I never reproduced such problem, could you give some more details about your configuration: which servlet engine are you using? Do you use a specific URL configuration? Are you using XWiki behind a proxy that could rewrite URLs?

We use tomcat-9.0.63, we have set “xwiki.webapppath=ikmz/xwiki” and deployed to ikmz#xwiki, 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].

[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: Loading...

[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