Drag and drop of a image in the WYSIWYG editor does not work

Enviroment:
OS: Debain 10
xwiki version 14.5
3 subwikis migrated from an older version of xwiki (13.x)
2 subwikis cretead in xwiki 14.5

Only in the subwikis created with 14.5 drag and drop of a image into the WYSIWYG editor does not work. In the other subwikis it works without a problem.

For the subwikis created with 14.5, the message “file successfully upload” appears, the image is shown properly in the WYSIWYG Editor and after the saving the page, all seems to be perfect.
But after reloading the page, the image is gone, only the link to a non existing attachment is shown.
The attachment is missing.

In the catalina.out there is a message for these not working images (which are not in subwikis created with xwiki 13.x):

[2022-07-23 09:03:33] [info] 2022-07-23 09:03:33,753 [http-nio-8080-exec-8 - http://localhost:8080/xwiki/wiki/ventus3t/download/Main/WebHome/image-20220723090312-1.jpeg] WARN  c.x.x.p.XWikiPluginManager     - downloadAttachment failed for plugin [image]: null
[2022-07-23 09:03:33] [info] 2022-07-23 09:03:33,753 [http-nio-8080-exec-8 - http://localhost:8080/xwiki/wiki/ventus3t/download/Main/WebHome/image-20220723090312-1.jpeg] WARN  c.x.x.p.XWikiPluginManager     - downloadAttachment failed for plugin [zipexplorer]: null

Attaching a file and choose it as a image works.

Any hints?

Regards Rainer

Hello Pulsar07,

I don’t know if it’s related and haven’t tried to reproduce this issue, but I would say you should try to check whether the image plugin of the editor is different between the wikis where it works and the wikis where it doesn’t work . See the documentation here https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/#HImageAttachments , the part that starts with 1.62.

Let us know how / if this solves your problem!

I tried a lot the last days using a virtual server with a new XWiki-Installation.
The result is:
When a subwiki is created all works fine.
After switching the default language to German, the “Home” page is gone and a new “Startseite” is created (the content of the Englisch “Home” content is completely gone and replaced by the default content of a new created subwiki home page. And exactly in this new automatically created “Startsteite” the problem occurs. And only there. All other pages work fine. Also new created pages work fine, only on the “Startseite” (:8080/xwiki/wiki/testwiki2/view/Main/?language=de#) drag and drop a images, are well shown, can be perfectly saved, but after reloading the page the attachment is not existing anymore and the link to the image on the page have become orphaned.
Creation of a new page and making this page to the new HOMEPAGE (Wiki Administration->Wikis->Descriptor->HOMEPAGE) “solves” the problem.

Hi lucaa,
due to the fact, that all but the “Startpage” (see my other reply) work, I guess there is no dependency to a different list of used plugins of the editor.
Nevertheless I enabled the xwiki-image plugin an tested with it. But it was the same behaviour with plugin xwiki-image and xwiki-image-old.

But there was one more detail I was not aware of before. The problem is not only at “drag and drop” of a image into the editor, it is the same effect, if I use “insert image” dialog (either xwiki-image or xwiki-image-old. At the end the attachment is not existing.
Attaching a image file in the attachment area works.

Rainer

Ok, looks like it’s a problem related to page translations and how a page’s metadata is handled across translations.
In the Standard flavor package, that provides the default homepage of the wiki, the homepage is a translated page, in many languages, so that when XWiki users install the default flavor and switch their wiki language to their language, they see the explanation text on the homepage in their language.

Translated pages feature is implemented in a way in which translated page shares with the original page the same URL (reference), but they are still partial different entities at database level, while still sharing some metadata. So, since it doesn’t happen on other pages, it looks like it’s related to this.

The idea would be to try to reproduce the same conditions: what is the language setting (in the wiki administration) for the wikis that work vs. wikis that don’t work?

Sorry, maybe I have not made it clear enough. All my XWiki instances (on different (virtual) servers) behave in the same way.
I can reproduce it on all my XWiki instances. I can reproduce it with German and Norsk (did not try it with others !)
Description how to reproduce it:

  • use a XWiki with English as DEFAULT LANGUAGE (Wiki Administration → Content → Localitzion
  • switch to a other DEFAULT LAGUAGE (for which the standardt flavor package does force a translation) and save this setting
  • go to the new translate Startpage/Home page
  • edit the Startpage and try to put a image into the Startpage
  • save the Startpage
  • The Startpage looks fine, the picture is shown.
  • use the browsers reload button to force a reload of all image resources
  • the image is gone and only the orphaned link is shown

I can reproduce also, on XWiki 14.4.1.

To me it looks like a regression.

It’s already really really cool that you helped us find this issue, @Pulsar07, would it be too much of me to ask you to report the issue with these steps (and screenshots?) on https://jira.xwiki.org/ ?

Thanks a lot,
Anca

@Pulsar07 and also @lucaa could you check if the solution mentioned in Adding images per drag&drop or from clipboard in CKEditor fails - #7 by surli fixed the problem for you? I wasn’t able to reproduce back then.

I confirm I don’t reproduce anymore if I add

config['xwiki-upload'].isTemporaryAttachmentSupported = false

in the wysiwyg editor configuration in the wiki administration.

So to me this is a bug of the xwiki-upload plugin, of this new temporary attachment feature.

Reproducing the problem is very straightforward to me, on any translated page - e.g. on Sandbox.TestPage1 with the wiki in french. It reproduces all the time.

that’s the information I was previously missing. @mflorea has been able to reproduce too on a translation. I will fix that.

The fix/workaround in the extended configuration of the WYSIWYG works also on my wikis. Thanks for help.

Is it possible to use this configuration fix, without drawbacks ?

So I created a ticket to fix this issue, you can follow it up there: Loading...
Regarding the drawbacks, this configuration has been introduced as part of the changes made for Loading... so basically you’ll rely on the old way of saving attachment when using this configuration: the document will be saved each time an attachment is uploaded, instead of being saved whenever you click on a save button.