TYPO3 Core

Exchanging just the sysext rtehtmlarea (2.0.7 in 4.4.5 to 2.0.5 from 4.4.4) does not help it. So I suspect formating is stripped somewhere else ...

Root-cause for this is not the upgraded rtehtmlarea, as I expected, but a change in t3lib_parsehtml. Reverting that change makes it work as before again.

Change occured in revision 9138:
http://forge.typo3.org/projects/typo3v4-core/repository/revisions/9138
2010-10-18 13:29 Xavier Perseguers
Fixed bug #14884: 'removeTag' does not remove closing tags

That was a LONG standing but (for 2 years) that finally got fixed. Hmm ... Any chance to maybe re-think the fix?

How to reproduce:
1) Add a normal text-element to a page. Apply bold-formatting to a word using rtehtmlarea. That results in something like

abc <span style="font-weight: bold;">def</span> ghi

in html-view.

2) Click on "save".

Expected behaviour (works with 4.4.4):
1) Text is saved with bold formatting.
2) When RTE reloads the bold formatting is still there.

Result with 4.4.5:
1) When RTE loads the bold-formatted text shows up fine but
2) saving it removes the bold-formatting. That is done in the html-parser for the case "rte" (processing of data on it's way from RTE to database).

Text is then:
abc def ghi
(Same text, but span-formatting stripped)

I can reproduce the issue after upgrade from 4.3.8 to 4.4.5. span gets removed after saving.

Does "All formating" mean formating with the style attribute?

Is the RTE extension variable "Enable features that use the style attribute" set in the Extension Manager"?

I can confirm that. All span tags are now stripped. Also those for text styles.

IMO the severity of this issue should be raised to "block". If no simple solution can be found, 0001318 should be reverted. It was nice to finally have a fix, but we have lived with it for years...

@Stanislas: Yes, allowStyleAttribute is enabled and was enabled before.

Looking at the code I'm sure that not only "span" but at least for example "font"-tags and the like are stripped as well.

In class.t3lib_parsehtml_proc.php around line 1164 this is the place where rmTagIfNoAttrib is set to "1" for "span" and "font" (if they appear in keepTags, which comes from the list of allowed tags). So that way they are "forced" to 1. In general, if it works as designed, imho that's not a problem for span and font, since if they are empty they could really be left out.

Then in class.t3lib_parsehtml.php the condition checks:
if ($endTag || trim($tagParts¹) || !$tags[$tagName]['rmTagIfNoAttrib']) {
Fine, since we want to keep end-tags, want to keep all which have attributes (result of the trim) and all tags which are not flagged to be removed if they don't have attributes.
But on the next line $setTag is set to false if rmTagIfNoAttrib, not taking into account if tagParts was empty or not (or if this was an endTag). Scrolling further through the conditions below that they are not taken into account and after that is a final if ($setTag) And since $setTag is false that tag gets left out. So imho it's clear that it can't work as it is now. I'm unfortunately not sure about the referenced bug which this change tries to have fixed (how that bug was meant), but at least it seems that this fix broke other things.

I have the exact same behavior and narrowed it down to the same point as Stefan. Reverting the code to $setTag = 1 resolves this issue (but very probably returns the 'fixed' bug...).

EDIT: Weirdest thing is: placing the span-tag in e.g. a h2-tag keeps it. For me it happend in p-tags. BUT if you surround the p-tag with a div-tag the span is also kept...

In my case reverting the code to $setTag = 1 does not resolve the issue. In any case: in 4.3.8 everything was fine and nothing except the Typo3 Version has changed...

@Martin: do you specify property
rmTagIfNoAttrib
anywhere in your Page TSConfig?

Yes, I have set

RTE.default.proc.entryHTMLparser_db.rmTagIfNoAttrib = span,div,font

I made a further test: I took my standard TYPO3 bundled running on TYPO3 4.4.4 and could set a text style (which translated into something like "span class="large""text"/span"). Upon saving the span tag was preserved as expected.

I then switched the same install to the current 4.4 development branch. I opened the content element in which I had previously applied the text style and just hit the "Save" button. The span tag was removed. I'm attaching my full RTE config to this report.

Also the other new versions 4.2.16 and 4.3.9 have the same failure, not only the 4.4.5!
A security-patched 4.4.4 (patched by Mittwald) will work properly.

I can confirm this issue in a few installations which i upgraded from 4.4.4 to 4.4.5.

I haven't tested this deeply but could that be a solution:

$setTag = ($endTag || trim($tagParts¹)) ? 1 : !$tags[$tagName]['rmTagIfNoAttrib'];

We have recognized that tags like:
[a class="internal-link" href="record:tt_news:4403"]Diabetes[/a] - angle-braces of course instead of square-brackets

from link-handler won't work anymore. They are simply removed to "Diabetes".

On our local 4.4.4 instance, everything still works fine

Why not
"$setTag = 1"
like in Version 4.4.4!?
I replaced the new statement with the old one in the updated versions.

What was the reason for this new statement:
$setTag = !$tags[$tagName]['rmTagIfNoAttrib']
?
Nevertheless this statement is wrong. If "$tags[$tagName]['rmTagIfNoAttrib']" is set, all span's will be removed allthough there is an attribute in: class="green" e.g.

@Uwe:

setTag = ($endTag || trim($tagParts¹)) ? 1 : !$tags[$tagName]['rmTagIfNoAttrib'];

is the same as

setTag = ($endTag || trim($tagParts¹)) || !$tags[$tagName]['rmTagIfNoAttrib'];

which is the condition for entering the if-clause.

Therefore, it is equivalent to:

$setTag = 1

Hmmm. First I set "$setTag=1;" on line 908 in the class.t3lib_parsehtml.php. That didn't do anything, the spans kept disappearing. Today, after i read Kurts message, I set "$setTag = !$tags[$tagName]['rmTagIfNoAttrib'];" in line 878 to "$setTag=1;"

Now it works fine and the spans are not removed anymore!

I think the Problem is caused in

class.t3lib_parsehtml_proc.php in line 1165

rmTagIfNoAttrib for span-elements is set to 1 no matter what configuration I add to my TS-Config.

Why is there a default config for $keepTags['span'], or how can i override it with TS?

Sincerely

lygie: I think the default-config is okay, since it makes no sense to keep empty span-tags around. The problem imho is not that it's 1 by default but that it doesn't actually do what it's supposed to do. Setting it to 0 (if possible) would cause spans to stay - but that's just curing symptoms not causes :-)

I think the problem is due to the fix introduced by #0001318.

$setTag = 1 must remain.

In this instance of the processing loop, if we are processing a closing tag (endTag), then the contents trim($tagParts¹) is always null because it contains the contents of the closing tag, not the contents of the opening tag. At this stage, there is no obvious way to test the contents of the opening tag in order to remove the closing tag if the opening tag was removed.

@Stanislas: You're right of course - stupid me hasn't thought this through enough...

@all review: Stanislas has proposed a solution in issue 0001318. I have attached it as a patch to this issue. Please test it to confirm if this solves all your problems. If it does we can fix this problem, otherwise we'll revert the fix to 0001318.

Testet attached patch with 4.3.9: all span tags remain, also text styles and links

I noticed the same problem (disappearing span tags upon save in RTE) on an installation running 4.2.16.

The posted patch solved the issue.

The same issue arises with the RTE "tinymce_rte" (of course). The patch solves the issue there too.

Thanks!

Tested attached patch with 4.4.5. - patch solved the issue!

The Problems with links in RTE as described before are also solved with applied patch.
So problem solved here, too

Patch committed to trunk (revision 9867), branch TYPO3 4.4 (revision 9868) and branch TYPO3 4.3 (revision 9869).

Committed to TYPO3 4-2 (rev. 9888)