Item14473: HTML2TML conversion strips attributes that should be protected by WYSIWYGPLUGIN_STICKYBITS
Priority: Normal
Current State: Proposal Required
Released In: n/a
Target Release: n/a
We have come across a problem involving wysiwyg html2tml conversion. We would like to be able to create custom lists that are visible both in the final topic and when editing with
TinyMCE. For our implementation we would like to add the class attribute to the html tag ul. Then we can define custom styles by adding different classes.
By default lists are converted to TML by the wysiwyg plugin when saving. To prevent this from happening we have added the class attribute for UL tags in WYSIWYGPLUGIN_STICKYBITS. Indeed this addition prevents conversion of ul lists from html2tml, however, the class attribute is stripped off. We have confirmed this is not an issue with
TinyMCE, which retains the ul class attribute. Here are our WYSIWYGPLUGIN_STICKYBITS settings.
* Set WYSIWYGPLUGIN_STICKYBITS =
(?!IMG).*=id,lang,title,dir,on.*;
A=accesskey,coords,shape,target;
BDO=dir;
BR=clear;
COL=char,charoff,span,valign,width;
COLGROUP=align,char,charoff,span,valign,width;
DIR=compact;
DIV=align,style;
DL=compact;
FONT=size,face;
H[0-9]=align;
HR=align,noshade,size,width;
LEGEND=accesskey,align;
LI=value,class;
OL=compact,start,type;
P=align;
PARAM=name,type,value,valuetype;
PRE=width;
Q=cite;
TABLE=align,bgcolor,.*?background-color:.*,frame,rules,summary,width;
TBODY=align,char,charoff,valign;
TD=abbr,align,axis,bgcolor,.*?background-color:.*,.*?border-color:.*,char,charoff,headers,height,nowrap,rowspan,scope,valign,width;
TFOOT=align,char,charoff,valign;
TH=abbr,align,axis,bgcolor,.*?background-color:.*,char,charoff,height,nowrap,rowspan,scope,valign,width,headers;
THEAD=align,char,charoff,valign;
TR=bgcolor,.*?background-color:.*,char,charoff,valign;
UL=compact,type,class
We are using the current versions of wysiwyg plugin and
TinyMCE plugin in Foswiki 2.2.0 Alpha. We have also reproduced the problem on trunk.foswiki.org in the Sandbox -
TestSTICKYBITSlists
Simpliest way to see the problem is to add the class attribute to WYSIWYGPLUGIN_STICKYBITS for UL. Then input a list in the source code editor of
TinyMCE with a class attribute. For example:
<ul class="custom">
<li>Item one</li>
<li>Item two</li>
</ul>
When saving the topic the list will remain as html but the class attribute will be stripped off. My understanding is that attributes listed in WYSIWYGPLUGIN_STICKYBITS should be kept. If you try the same procedure with the type attribute, which is listed in STICKYBITS by default it is kept. For example:
<ul type="square">
<li>Item one</li>
<li>Item two</li>
</ul>
I think this might be a bug in the
HTML2TML script in the wysiwyg plugin or we misunderstand the intended functionality. Any help/suggestions would be very much appreciated.
--
KarlDuderstadt - 08 Sep 2017
Seems the class attributes are stripped on in Node.pm in the function _htmlParams. This is because by default VERY_CLEAN is on so the following lines strip off any classes that don't have foswiki in the name or are not part of
ChiliClass:
CLASS: for my $class ( split /\s+/, $v ) {
next CLASS unless $class =~ /\S/;
next CLASS if $tml2htmlClass{$class};
# if cleaning aggressively, remove class attributes
# except for the JQuery "Chili" classes
next CLASS
if ( $options & VERY_CLEAN
and not $jqueryChiliClass{$class}
and not $class =~ /^foswiki/ );
push @classes, $class;
}
Lines 697 to 711.
I have added foswiki into the names of all my custom classes and they are no longer stripped off. I guess another options would be to turn off VERY_CLEAN but I am not sure the other consequences of doing that so I will keep this solution. Also, this means there should be no problems when further released come out.
It seems that class is considered a special attribute, so other attributes in sticky bits shouldn't be stripped. It would be very helpful it this was mentioned in the documentation and/or it was possible to set VERY_CLEAN without editing the perl code.
Well at least this task item should help others with a similar problem in the future.
--
KarlDuderstadt - 18 Sep 2017
Thanks for the debugging and suggestions. Crawford, if you get some time could you review this? This is too deep in the Wysiwyg processing for me.
--
GeorgeClark - 12 Dec 2017
Really this requires a simple code fix (improvement). Karl has identified the right place in the code for a "keep these classes" option (WYSIWYGPLUGIN_STICKYCLASSES, perhaps?) that should also handle the chili classes. If WYSIWYGPLUGIN_STICKYCLASSES handles regexes (or wildcards), you could e.g. WYSIWYGPLUGIN_STICKYCLASSES=foswiki.*,jquery.*,custom.*,
Follow up in a task.
--
Main.CrawfordCurrie - 18 Jan 2018 - 11:16