Bug #83424
closed
Typo3 v8.7 crashes <abbr> tags
Added by Λάθε βιώσας over 6 years ago. Updated almost 5 years ago.
100%
Description
After migration from v7.6 to v8.7 all opening <abbr> tags are changed to
lt;abbr> <pre> If I want to write a new <abbr> tag it is deleted after saving.
Updated by Riccardo De Contardi over 6 years ago
- Status changed from New to Needs Feedback
You should modifiy the configuration of CKEditor and use a custom .yaml file - see https://typo3worx.eu/2017/02/configure-ckeditor-in-typo3/
Add this code:
editor:
config:
extraAllowedContent: "abbr"
It seems to work for me, could you confirm? Thank you!
Updated by Riccardo De Contardi over 6 years ago
- Category set to RTE (rtehtmlarea + ckeditor)
Updated by Λάθε βιώσας over 6 years ago
- Related to Bug #83422: Rendering of </tag> <abbr title="xxx"> kills space added
Updated by Λάθε βιώσας over 6 years ago
Sorry, I made on the same day a full rollback to v7.6 because a clean XHTML output has absolute priority. Especially I did not like the perspective to repair many hundreds of content element - many of them with sophisticated semantic tagging.
Also I do not understand what the RTEs have to do with this problem because rtehtmlarea is not installed and the new one is not activated. I use the standard "Text & Media" type of fluid_styled_content from Typo3 v7.6 but without rich text editor because I want clean XHTML and not any editor rubbish. In v7.6 it was working without any problems but v8.7 seems to have problems with some standard (X)HTML tags like <abbr>.
Updated by Riccardo De Contardi over 6 years ago
- Category changed from RTE (rtehtmlarea + ckeditor) to Frontend
- Status changed from Needs Feedback to New
Ok, sorry I did miss that you did not have RTE enabled; I change the category to frontend and try to test it again.
So, the steps to reproduce your issues are
1) disable RTEHtmlarea and CKEditor
2) create a text element
3) put in it code like
<abbr title="example">ex.</abbr>
4) Result: the <abbr> is changed to <abbr>
Have I forgot something?
Updated by Λάθε βιώσας over 6 years ago
Nearly, there are two cases:
A
In Text & Media elements migrated from v7.6 the former <abbr> tags are coded
<abbr>, but in the source code of the frontend they appear again as <abbr> tags:
The main problem is that it is very difficult to read the code in the backend if you want to change something especially because you are expecting that it would render <abbr> on the page (
<abbr>in the source code). Also I want not to have the problem that I have to correct many hundred of content elements with perhaps far over thousand <abbr> tags back again if there is any change.
B
When I create a new content element or edit a old content element, all new written opening and closing <abbr> tags are not saved.
I think - together with some related problems - the problem of v8 is that in all the euphory for the new RTE also the core system of Typo3 was optimized just for it without checking whether it works also in the hard core way without any RTE.
Updated by
Updated by Benni Mack over 5 years ago
Hi,
thanks for your report and you're right - we've simplified the RTE processing configuration and did not provide proper defaults when no RTE is available.
Two solutions:
a) create a 'default' RTE configuration.yaml like in EXT:rte_ckeditor (register in ext_localconf.php of your own extension) and use the EXT:rte_ckeditor/Configuration/Rte/Processing.yaml as template.
b) Add this PageTSconfig option RTE.default.proc.allowTags := addToList(abbr)
We'll also create a patch to fix this in the next v8 version.
Updated by Gerrit Code Review over 5 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58745
Updated by Gerrit Code Review over 5 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58749
Updated by Benni Mack over 5 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 95aeaf184a103e24398ed82727286343337ed206.
Updated by Benni Mack almost 5 years ago
- Status changed from Resolved to Closed