Bug #102202
closed
RteHtmlParser: Wrong caching for getKeepTags
0%
Description
We tracked down problems with the RTE where it was not possible to add proper processing-instructions for a custom preset. In our site-package we had a RTE-yaml-configuration which included:
processing:
allowTags:
- form
- input
But those tags weren't recognized. It turned out that in typo3/sysext/core/Classes/Html/RteHtmlParser.php, function getKeepTags() there is a cache $this->getKeepTags_cache which got filled by the default-RTE-configuration of a previous field and the tag-list compiled there was later used against another field with out custom-configuration. Emptying the cache in this function, actually causing it to be compiled "fresh" every time, made the functionality respect the given allowTags-configuration for our field.
I can't say if the situation in newer TYPO3-versions is different. A newer CKEditor is integrated - but has the RteHtmlParser or the caching changed significantly?
I wonder why this hasn't turned up elsewhere. Was it a special case here maybe because of multiple RTE-fields in a flexform-configuration used on the TYPO3 backend? Would separate caching for each field have been used (separate RteHtmlParser-instances?) if the fields wouldn't have been part of one big flexform or so?
Updated by Georg Ringer 5 months ago
- Status changed from New to Needs Feedback
should have been solved with #101190, see https://review.typo3.org/c/Packages/TYPO3.CMS/+/80695 for the change.
can you check if still wrong?
Updated by Stefan Neufeind 5 months ago
- Status changed from Needs Feedback to Resolved
Patch looks correct, and I expect it should work that way for TYPO3 v10 as well.
Can't test the patch in our customers environment (which unfortunately still is TYPO3 v10 for now). They chose a different solution with disabled RTE for now.
Thanks for digging into this! I expect we can maybe declare this "resolved" (though TYPO3 v10 won't get a backport, as per release-policy).
Updated by