Bug #104837
open
CKEditor 5 regression: Empty paragraphs are not saved
0%
Description
In TYPO3 12, a CKEditor text body containing only empty paragraphs is no longer saved.
In TYPO3 10 and 11, with CKEditor 4, this is not reproducible. Thus, this is a regression in TYPO3 12, using CKEditor 5.
Steps to reproduce:
- Create a new content element with RTE field, e.g. Text & Media.
- Open the browser devtools and switch to the network tab, filter for HTML requests
- Focus the RTE field
- Press enter multiple times
- Save the record
- View the POST request in the devtools network tab.
- In TYPO3 10 and 11: It will show the empty paragraphs.
- In TYPO3 12: It will show an empty bodytext payload.
Example payload in TYPO3 10 and 11:
-----------------------------916450189548275757802288063 Content-Disposition: form-data; name="data[tt_content][43478][bodytext]" <p> </p> <p> </p> <p> </p> <p> </p> <p> </p>
Example payload in TYPO3 12 (regression):
-----------------------------336333994235977953473285274868 Content-Disposition: form-data; name="data[tt_content][43402][bodytext]"
Observations:
- The TYPO3 12 CKEditor 5 inspector (editor config `debug: true`) shows the empty paragraphs. This means that CKEditor 5's internal data model is not broken.
- In TYPO3 10 and 11 (CKEditor 4) and in TYPO3 12 (CKEditor 5), the hidden bodytext textarea is never updated on the fly. This is normal. This means that editing adding empty paragraphs, inspecting the hidden textarea and finding that it does not contain the same hidden paragraphs is not an indicator for failure. The hidden textarea had never been live-updated, even before the regression.
- When adding a single non-white space character, all empty paragraphs are saved. Only when the editor contains only empty paragraphs does it save nothing at all. It should, of course, save the empty paragraphs in any case.
Theories:
- CKEditor 5 might not inform TYPO3 that the content changed, as long as its content is only white space?
- TYPO3 might filter for non-whitespace content when considering if the form is changed?
- TYPO3 or CKEditor 5 might try to trim leading or trailing white space, and accidentally trim entire paragraphs? Note, though, that adding a single non-whitespace character to the editor's content makes everything get saved as expected, including empty paragraphs.
Updated by Leonie Philine about 1 month ago
- Subject changed from CKEditor 5 regression: Empty paragraphs are not stored in the hidden textarea and not saved to CKEditor 5 regression: Empty paragraphs are not saved
The regression is unaffected by the SourceEditing plugin.
I.e. the following does not make saving empty paragraphs work:
editor:
config:
removePlugins:
- SourceEditing
Updated by Garvin Hicking about 1 month ago
- Status changed from New to Needs Feedback
For me, when I edit the empty paragraphs, switch to Source code mode it is empty, and also becomes empty if I insert `<p> </p>` and switch back and forth again?
However, regression or not: I would argue that the HTMLParser at PHP-level here recognizes this all as "this is empty". And I would probably argue, it indeed is empty. You are somewhat abusing semantic markup for layout purposes - and IMO the better way to move forward is use other elements and spacing definitions.
Or create a "spacer" content element that you actually can use instead of varying amounts of whitespaces? I can understand to use this as a "hack" or workaround, but I think the actual trimming of the data is okay from a cleanup-perspective.
If you really want to use the whitespace, maybe you could utilize the HTMLParser event BeforeTransformTextForRichTextEditorEvent and AfterTransformTextForRichTextEditorEvent and alike, to preserve that? See https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/Events/Core/Html/AfterTransformTextForPersistenceEvent.html - or the former hooks which should be available in T3v12.
Updated by Leonie Philine about 1 month ago
For me, when I edit the empty paragraphs, switch to Source code mode it is empty, and also becomes empty if I insert `<p> </p>` and switch back and forth again?
This is not relevant, as source code mode is not involved in the described regression.
you could utilize the HTMLParser event
Any attempts on PHP level will be fruitless, since the HTTP POST request already contains an empty bodytext.
This is a purely client-side regression.
And I would probably argue, it indeed is empty.
It is not empty. It is white space.
You are somewhat abusing semantic markup for layout purposes
There are legitimate reasons for empty paragraphs. This is why the feature is supported in the first place:
The within the <p> are not created by me (e.g. in source editing mode), but by CKEditor (by normal WYSIWYG editing). This is a feature by design.
The bug lies in the fact that the empty paragraphs are no longer passed to the server. The HTTP Post bodytext payload differs from the editor content, which is unintended.
Updated by Leonie Philine about 1 month ago
I think the actual trimming of the data is okay from a cleanup-perspective
This is not trimming in the ltrim / rtrim sense. If a single non-whitespace character is anywhere within the bodytext, then the entire editor content is POSTed to the server.
No trimming occurs. I.e. leading empty paragraphs before the non-whitespace character, or trailing empty paragraphs after it are not trimmed.
This is not a trimming feature, but a bug.
Updated by Garvin Hicking about 1 month ago
What I was referring to - CKEditor5 seems to strip this. The submit basically does what entering Sourcecode mode and going out of it internally does. You can reproduce that in the CKEditor demo https://ckeditor.com/ckbox/demo/#ckeditor-with-ckbox for example.
TYPO3 does not manipulate the data that is put into the `form` input to my knowledge, CKEditor populates the form field.
I've checked but am unaware how CKEditor5 would allow to unconfigure this behaviour. Maybe you can help checking back with their support; if there's an option we can set on the TYPO3 side, we'll surely try to see if it can be made configurable in our YAML/JS, too.
My recommendation would really be to not utilize blank lines / spaces as means of layout/padding/margin insertion.