Advent Calendar : content won't update at a certain point [FOLLOW UP]

Hello !

I am using the H5P plugin on a Wordpress site (all updated to the latest version). I am creating an Advent Calendar. Earlier this week, I have made 3 of them with images popping up and everything was working fine (except for a cosmectic detail that I exposed in an other post).

Today, I tried to make a calendar with text popping up instead of images but it didn't go well : so maybe this has something to do with the new editor ?... Don't know, just thinking out loud.

First, I upload the door images and the back images : no problem there. Then I input some text. At first, the text is saved correctly, but at some point, the content-type gets stucked and it won't save my content anymore. The text that I input is removed every time I save the content and any other modifications are not taken into account. I first thought that I did something wrong with the first calendar ; so I started a fresh one from scratch but the same thing happens. On both calendars the result is the same : it get stuck at some point and I no longer can modify it.

I don't see any specific error in the log console - well no more than the usual : 

I have exported one of the H5P files in question and tried to import it here on h5p.org, but it won't load ; I receive a 500 error message. Files won't open in Lumi Desktop either nor on Zum. It makes me think that my H5P is corrupted maybe ? I attach the H5P file but PLEASE be careful : if it is corrupted, I don't want to spread any harm to other users (as Oliver pointed it out in one of his posts).

Any help and advice will be welcome and very much appreciated.

Cheers,

Isabelle

otacke's picture

This is an interesting one. It does not seem to be related to the content type itself, as it the editor is supplied by H5P core, as is the upload logic.

I can upload it just fine here:

  • local WordPress instance without any issues
  • H5P-CLI tool
  • Moodle sandbox with moodle's custom H5P integration
  • h5p.com (while the content uses version 0.3.5, h5p.com only uses 0.3.4. In theory, this should always work, as the parameter structure must be identical when the minor version is the same)

It fails, however, here on

Looking at this alone, something in H5P core and/or the H5P integrations might be odd.

Out of interest, I saved the file after uploading it to H5P.com and compared it with your file. There was nothing that struck me in particular, but it was only then that I noticed that the content.json file inside your package was ridiculously large (over 35MB). That's where the parameters that you enter in the editor are stored. Door number 22 hides Humphrey the parrot, and the text is full of hundrets of "background-color:rgb(255,255,255);". Same goes for a couple of the other fields with one of them accounting for 17MB.

Taking this into account, your assumption about the new version of the CKEditor might be correct. Unless you pasted the text from somewhere else (where it contained all the CSS values), the editor might produce this rediculous amount of text which may simple be too much at some point. That's when you'd notice the stalling.

Uploading the content then most likely simply fails depending on the server settings for uploading/handling files of that size, some internal timeout or similar resulting in different server side issues at some point leading to the different error messages.

@BV: Unless all the "background-color:rgb(255,255,255);" occurrences were not added by pasting the text from somewhere else, H5P Group might want to investigate this.

Hi Oliver (and BV) !

Let me express first how grateful I am that you took so much time to investigate this "conundrum" and with such great care : I can't thank you enough ! I have read your post as if it was an episode of "Elementary" : the narration of your investigation litteraly kept me on tenterhooks from start to finish and, as they say in the show, this is "good police work" :D

You nailed it ! I was about to write that I didn't copy-paste the text from somewhere else but then I remembered that I did copy-paste something : the emojis ! Of course, before posting on the forum, I had a look at the code-source but I didn't spot the ridiculous amount of "background-color:rgb(255,255,255);" occurrences behing each door (how did I miss that ?... ) And of course this is probably what causes the content to "crash"... Here is a preview for a single door : 

Notice that the thousands of "background-color:rgb(255,255,255);" are associated to the parchment emoji that appears right before the closing span attribute : I did indeed copy-paste this emoji from a website which provides emojis to copy-paste (https://emojiterra.com/fr/page-enroulee/) - so I am quite puzzled that it added so much code ;( The other emojis I used, I copied-pasted them from an other website (https://emojis.wiki/) and they are free of "background-color:rgb(255,255,255);".

So my guess is that the matter is caused by the first website I mentioned and that CKEditor is not causing this. But, to be sure, I will create tomorrow a new calendar from scratch (identical to the one I attached) but "emoji-free" : I bet that the content-type won't crash anymore. I'll report here when I am done.

I am confused and sorry that you lost time over this ridiculous copy-paste issue... There are 2 valuable lessons here for me : 1. check thoroughly the code-source before posting on the forum and 2. don't copy-paste from websites you don't know ;)

Thank you again for your help !

Cheers,

Isabelle

 

 

As promised, here is a follow up :

  • I have been able to successfully edit the Advent Calendar that wouldn't update anymore. All I had to do was to erase / remove all the parchment emojis from the 24 doors and, when I saved the content, it updated right away ; no trouble at all. So, Oliver was right : it was the added inline CSS code that caused this content to "crash".
  • Next, I spotted in the source-code the other emojis that were supercharged with inline CSS code and erased them as well.
  • Then I carefully reintroduced emojis in some texts, but I did an "unformatted / clean" copy-paste this time. My content saved right away and when I checked the code, no "background-color:rg(...)" showed up in the source.
  • I could then copy-paste emojis everywhere else I intended to use them, and - as expected by Oliver - the content didn't crash anymore.

I then tried to copy-paste emojis from the 3 websites I used and mentioned before :

  • the emojis from this site or this one are "clean" when pasted in CKeditor : no inline CSS code is added.
  • the ones from the third website are charged with some inline CSS code, but not as much as there was in the calendar I had trouble with. I have not been able to reproduce the ridiculous amount of "background-color:rgb(255,255,255);" that Oliver discovered : I don't know how I ended with so much gibberish code.

I don't usually embed emojis in my H5P contents - but, for sure, I will be more careful when pasting stuff in the future.

Thanks again, Oliver, for your investigation and help !

Best,

Isabelle

I am not sure that there isn't something "buggy" with CKeditor finally...

Today, I have been able to reproduce the ridiculous amount of "background-color:rgb(255,255,255);" that Oliver found in my content. I copied-pasted an emoji ; there was some inline CSS added in the source as I stated in my previous post. But, then, each time I save my content, this code grows and doubles, even if I don't edit anything. And the more I save my content, the more gibberish code the editor adds. Here is a demo of the weird "phenomena" (and as you can see, I don't have to edit the content ; I am simply hitting the "save" button) :

https://ibb.co/4ZZgLv6 (link)

So there maybe something to investigate after all with CKeditor, right ?... Because I am probably not the only one to copy-paste from other sources. If the editor duplicates the inline CSS code each time a content is saved, some users will eventually have their content crash.

I don't know ; maybe this is irrelevant, but still I wanted to point this oiut just in case.

Best,

Isabelle

otacke's picture

Yes, that's something that H5P Group should look into.