Priority: Urgent
Current State: Closed
Released In: 1.1.5
Target Release: patch
I've got pages with del HTML tags in them. When editing them with the wysiwyg, they are removed when either saving or switching to the wikitext view. They are not removed when using the HTML view. I have enabled xhtmlxtras and added a del button the tinymce toolbar, and the button appears to work, but the del tags are removed when either saving or switching to the wikitext view.
--
JayenAshar - 21 Dec 2011
Using
TinyMCEPlugin 1.1.10 and
WysiwygPlugin 1.1.2. About to upgrade and try again.
--
JayenAshar - 21 Dec 2011
Still in
TinyMCEPlugin 1.1.12 and
WysiwygPlugin 1.1.3.
--
JayenAshar - 21 Dec 2011
Confirmed. Raised to urgent.
--
PaulHarvey - 21 Dec 2011
-
<s>
is being stripped by TinyMCE
-
<del>
is being stripped by HTML2TML
-
<strike>
is being protected by TML2HTML
--
PaulHarvey - 21 Dec 2011
Why are any tags being stripped? Shouldn't HTML tags be replaced by TML?
--
JayenAshar - 22 Dec 2011
TML is far less expressive than HTML. Traditionally, people have complained that pasting from "noisy" sources such as rich text documents (from word or whatever), or even from other websites, results in HTML-ified code. So there's some attempt to ignore extraneous or unimportant styles etc. resulting in stripped tags/attributes to ensure clean conversion to TML.
But deleting these tags is a bug, plain and simple. Except that a quick look at the code didn't reveal any obvious place for me to start looking. Crazy.
--
PaulHarvey - 22 Dec 2011
Is there a way to disable the noise-removal? Is the definition of noise based on a whitelist or a blacklist?
--
JayenAshar - 22 Dec 2011
To whoever fixes this: please see if this also closes Item11471
--
PaulHarvey - 27 Jan 2012
strike
tags are not lost;
s
tags are eaten by TMCE, as Paul observes, which is fine by me as they are deprecated in HTML 4.01 and duplicate
strike
anyway. Which leaves
del
(and
ins
) tags to be retained. No problem.
L8r: this is fixed in trunk, but i can't merge to Release01x01 as there have been changes in one branch not reflected in the other, and now I'm hopelessly confused. AFAIK the branches should be identical for this plugin. Paul, help!
--
CrawfordCurrie - 28 Feb 2012
I know the branches should be identical, and I spent last Sunday, and the Saturday before trying to get the merge right.
Contributions to divergent branches include:
- My own work on trunk updating the test infrastructure. There's a new selenium API and I wasted some time trying to get us up-to-date (none of this work was pushed to svn); it's not a high priority so I'm stopping that effort for now (they still support the old API anyway, we just miss out on some nifty new features).
- MichaelTempest's important work on Item2174 hasn't been back-ported to Release01x01 because of Item11312,
- You yourself add support for new TML syntax in Item2516
- A few tests that have been added to trunk and not Release01x01
I read a comment on IRC "death by git branches", I wouldn't blame git here (unless you count that it makes it easier to have more divergent branches), we've just gone for too long without merging.
I have reviewed the test differences between trunk & Release0x01, my intention was to fix
Item11312 so that we can keep
Item2174 but I'm still unclear on what your strategy is to detect & disable the new TML syntax from
Item2516 when running on Foswiki 1.1.x
It will definitely be trunk -> Release01x01 merge, not the other way.
--
PaulHarvey - 28 Feb 2012
I just checked in code that should allow you to finish the merge (detects and disables the indent when running on a Foswiki that doesn't have it)
--
CrawfordCurrie - 08 Mar 2012
Fantastic! Thanks Crawford.
--
PaulHarvey - 08 Mar 2012