New or changed article not saved when pushing save without error message

[PoML]

Link to my forum: https://smbergen.org/medlemmer/forum/index.php
SMF version: 2.1.2
TP version: 2.2.2
Default Forum Language: Norwegian
Theme name and version: SMF Default Theme - Curve2
Browser Name and Version: Chrome 106.0.5249.119
Mods installed:
2   Event Registration Mod   0.19a   
6   SMF Gallery Lite   7.1   
10   TinyPortal   2.2.2   
Related Error messages: None

We have used an HTML article with a tailor-made heading using tables for a newsletter-article.
The last time this was created/edited, the author reported a frustratingly disappearing of edits when using save.
I went in to the same article, and found for a while 2 versions of the article after each other.  Believing the author simply did not know better, I edited it and saved. To my surprise, the changes after save was replaced again by the "before editing" version but this time all MY edits were truly gone.

I have a couple of suspicions of what may be wrong, and did a thorough manual review of the top table.
This seemed to fix the issue (ie I have not been able to replicate the issue)..

I would like to hear your comments:

1) Have anybody else seen a similar issue?
2) Could there be a difference on which of the two versions of the "save article" button that is used? I hope and think the save under the article and under the options both do the same?
3) Could an error in the HTML lead to bugs (ie is the saved html not sanitized?) The HTML was generated by copying from a google docs document and thus more complex than one might want. Is that something not supported? (HTML below)
4) What happens if two users are both logged in and in change mode of an article=  Could there be a conflict?

Code: [Select]

<table style="width:100%; text-align: center; margin: 0px auto 0px 0px; padding: 0px; empty-cells: show; box-sizing: border-box; background-color: rgb(0, 0, 0); border-spacing: 0px; text-size-adjust: auto; color: rgb(0, 0, 0);" class="SMB">
<tbody style="border-width: 2pt; border-style: solid; border-color: rgb(255, 255, 255) rgb(0, 0, 0); border-image: initial; empty-cells: show; min-width: 2px; box-sizing: border-box; padding: 2pt; margin: 0px; vertical-align: top; background-color: rgb(0, 0, 0); width: 800px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;" class="SMB">
<tr>
<td style="border-width: 1pt; border-style: solid; border-color: rgb(255, 255, 255) rgb(0, 0, 0);font-weight: 700; font-size: 16px; color: rgb(255, 255, 255);" class="SMB">
.
</td>
</tr>
<tr>
<td style="border-width: 1pt; border-style: solid; border-color: rgb(255, 255, 255) rgb(0, 0, 0);font-weight: 700; font-size: 24px; color: rgb(255, 255, 255);" class="SMB">
<br />SMBREV
</td>
</tr>
<tr>
<td style="border-width: 1pt; border-style: solid; border-color: rgb(255, 255, 255) rgb(0, 0, 0);font-weight: 400; font-size: 14px; color: rgb(255, 255, 255);" class="SMB">
November 2022
</td>
</tr>
</tbody>
</table>


[@rjen]

1) Have anybody else seen a similar issue?

I cannot say that I do, but I have seen some strange behavior before when people were copying extensive HTML from other sources, such as formatted texts from Word documents....

2) Could there be a difference on which of the two versions of the "save article" button that is used? I hope and think the save under the article and under the options both do the same?

Those buttons do the same thing, they are just there for convenience...

3) Could an error in the HTML lead to bugs (ie is the saved html not sanitized?) The HTML was generated by copying from a google docs document and thus more complex than one might want. Is that something not supported? (HTML below)

Yes, that is possible, hoewever I just checked the sample you provided and it works and saves fine on my test site

4) What happens if two users are both logged in and in change mode of an article=  Could there be a conflict?

Technically yes, there can be a conflict that the last person that presses save overwrites the artictle that was just saved by the first person: there is no locking mechanism.
It seems a bit strange that there are two version of the article stored: the articles use an incremental page id for identification: when changing an article the page id should not be changed.
Do you still have the both articles? What are the page id's?

[PoML]

Thanks for that - it certainly rules out a lot of possible causes.

Page IDs were 55 and 56. The second copy/page id was created manually just to be able to experiment with the problematic one without changing it, and being able to publish the article without leftovers in the database creating more issues.

If there is no auto-save on refresh/idle from browser then I think we can rule out the conflict scenario.
I am left with somehow bad code in HTML creating a refused save without the front-end clearliy warning about it or some corrupt data in the saved article in other ways.
Everything worked fine with the second attempt with a new article manually reducing complexity of copied HTML and then working with that. 
The only other alternative I see are random acts of God, that I can swear that I have witnessed in various software.

[PoML]

On this topic, I have found a few hints as to what causes it to go wrong:

1. Switching between html code and wysiwyg editor.
2. removing extra newlines that sometimes "just appear" when saving
3. Adding non-supported unicode-characters.

Last night both the two latter happened.
After reading that SMF now supported the full unicode specification, I of cource had to push my luck by adding this string between two chapters in an article:

🎄🎅 🎄  🤶  🎄 ❄ 🎄 ☃  🎄  🎁   🎄 ⛄  🎄  🛷  🎄  🔔 🎄  🎇 🎄  🎉 🎄

Result?
First this error when saving:
Incorrect string value: '\xF0\x9F\x8E\x84\xF0\x9F...' for column `c5jnzrz36_db538176`.`smf_tp_articles`.`body` at row 1
(the `c5jnzrz36_db538176` is simply the backend slightly cryptic database name)

Then I tried to remove and save again.
Then I suddenly had a lot of extra newlines.
Then I had two copies of the full article and I ended up with a "memory full" error from the backend.

As several of these symptoms are the same, I start to believe that if the HTML is wrong or contains non-supported characters then there is a flawed error handling somewhere.

Dont't know if that helps to find the root cause, but at least some of the symptoms should be an easy fix.

One is that the data type for an article should support what you can have in normal forum messages. As show above, there was no error saving this text here...?

Second is that somehow it seems from time to time a function to insert extra newlines is triggered when saving. A little like if you tick the "add
 in html email" in the newsletter send feature of SMF.
Is this a good hint to what is wrong?

Debugging error handling is worse - I know, that can be a nightmare.


Thanks for any help!