WYSIWYG editors considered harmful for site admins (and in general, but that's a sepa

Hi,

A while ago I got this bug report for pathauto:

http://drupal.org/node/
121276

I tried and tried but couldn't reproduce the thing.  As you
can read
from the issue it was quite confusing.  That was
frustrating.

Then today someone figured out that their WYSIWYG editor was
inserting
an   into the textarea.  That was the cause of the
bug.

Chx suggested we handle this in the following manner:
   Can't we have a warning on he WYSIWYG editor project
pages that if
   "you use this module, you are not entitled to
support on core, any other
    module and also, security is your problem now, not
ours?"

Thoughts on other solutions?

I'm thinking about going through all the WYSIWYG editors and
adding a
critical issue that they disable themselves on all textareas
in the
admin/* url-space.

I post this here because I want to

1) get some collective ideas on brainstorming
2) warn other users from using WYSIWYG editors on admin/
pages
3) alert module maintainers that if your settings page has a
textarea
input you should be aware of this as a possible cause of
problems

Regards,
Greg

Greg Knaddison - GVS wrote:
> I'm thinking about going through all the WYSIWYG
editors and adding a
> critical issue that they disable themselves on all
textareas in the
> admin/* url-space.
> 
> I post this here because I want to
> 
> 1) get some collective ideas on brainstorming
> 2) warn other users from using WYSIWYG editors on
admin/ pages
> 3) alert module maintainers that if your settings page
has a textarea
> input you should be aware of this as a possible cause
of problems

Greg, the site mission statement, footer and other settings
definitely 
need a textarea for easier editing for newbies. Turning off
wysiwyg on 
all admin/* is IMHO not an option. Maybe we can add FAPI
hints on 
textareas (a new FAPI property of a textarea) to allow
wysiwg editing, 
and label such 'frontend' content with this propery. Or the
other way 
around, label disallowed textareas, where a visual editor
should not be 
used. Then this can be generated into the HTML, and editors
should obey.

Gabor

On 3/12/07, Greg Knaddison - GVS <Greggrowingventuresolutions.com> wrote:

> I post this here because I want to
>
> 1) get some collective ideas on brainstorming
> 2) warn other users from using WYSIWYG editors on
admin/ pages
> 3) alert module maintainers that if your settings page
has a textarea
> input you should be aware of this as a possible cause
of problems

This was discussed briefly in #drupal.

Basically, as a best practice, we should tell WYSIWYG
modules to look
at filter_form and/or check using JS to see if an input form
selector
is available, and only then replace with a rich text area.

Hopefully chx and/or UnConeD can provide some more tips
here. I'm sure
that module devs for rich text would love some guidance on
this.

And yes, a "real" hook for D6 would be even
better, although I get the
sense many folks are against WYSIWYG in general, but I'd
rather not
get into a religious war....

-- 
Boris Mann
Vancouver 778-896-2747
San Francisco 415-367-3595
Skype borismann
http://www.bryght.com

> Maybe we can add FAPI hints on 
> textareas (a new FAPI property of a textarea) to allow
wysiwg editing, 
> and label such 'frontend' content with this propery. Or
the other way 
> around, label disallowed textareas, where a visual
editor should not be 
> used. Then this can be generated into the HTML, and
editors should obey.

See http://dr
upal.org/node/81297#comment-203670

> Basically, as a best practice, we should tell WYSIWYG
modules to look
> at filter_form and/or check using JS to see if an input
form selector
> is available, and only then replace with a rich text
area.

I ended up with something like that when I couldn't find a
way to
control which fields the TinyMCE module should pimp. I made
a small
custom module used filter_form() to give my chosen textareas
the class
of mceEditor, and used hook_menu(!$may_cache) to load
TinyMCE and
instruct it to only pimp textareas with the mceEditor
class.

I've been thinking whether to contact the devs of TinyMCE
module about
this, should I still or are they already on it?

> And yes, a "real" hook for D6 would be even
better, although I get the
> sense many folks are against WYSIWYG in general, but
I'd rather not
> get into a religious war....

It would make it easier, and I think it would promote
better
implementation of WYSIWYG editors, although filter_form()
and
hook_menu(!$may_cache) JavaScript will do it.

On 3/12/07, Boris Mann <borisbryght.com> wrote:
> Basically, as a best practice, we should tell WYSIWYG
modules to look
> at filter_form and/or check using JS to see if an input
form selector
> is available, and only then replace with a rich text
area.
>
> Hopefully chx and/or UnConeD can provide some more tips
here. I'm sure
> that module devs for rich text would love some guidance
on this.
>
> And yes, a "real" hook for D6 would be even
better, although I get the
> sense many folks are against WYSIWYG in general, but
I'd rather not
> get into a religious war....

I suggested adding a #format option to textareas over at
http://drupal.org/node
/125315. This would consistently add the input
format selector rather than requiring a separate element in
your code.
This would make it easier to detect the presence of the
selector since
it is more consistent.

-- 
Neil Drumm
http://delocalizedham.com

I'm in Austin right now and more than a bit buzzed (thanks
collegehumor.com, the Onion, and Salon for the beer and
sushi!).   if
you are interested in the direction of TinyMCE, pleaase join
the
TinyMCE developers group on groups.drupal.org.  Also, I
think I'm
doing the Dojo lesson this Sunday about the new
functionality Nedjo's
patches have (re)enabled.

TinyMCE has emerged from it's dark days and thanks to Nedjo
has a very
bright future.

BTW... the 4 Kitchen guys have been doing a great job
promoting Drupal
at SXSW and BarCamp Austin.  Their PressFlow module are
REALLY slick.
Everyone should be looking at what they are doing with
theotherpaper.com.

- Kevin

> I think this is a very good idea. 

No. It would endorse WYSIWYG editors which are a pestilence,
enemy of mankind, which should be outlawed.

Unlike the decree above, I was dead serious about adding
that note to WYSIWYG editors, especially fckeditor and
tinymce .

They are proven to break other modules and endorse very bad
practice, see font tag and other style things that users
have nothing to do with -- wymeditor is an exception here
(so is quicktags because that's not a wysiwyg editor). They
break the 'user input is sacrileged' philosophy -- I know, I
was forced to use tinymce for a little while up until one
day I needed to reformat some lengthy text where the
linebreaks got garbled totally.

I think some developers need to lay their personal issues
with WYSIWYG
editors aside and acknowledge that it is wanted and needed
by many end
users of Drupal. It's something so important for so many
users (also
potential ones) that it should be something easy to
implement and safe
to use.

I see the issues many developers have with these editors.
But instead
of writing it off as the devil's work, we should promote the
safest
possible use of these editors, particularly in the handbook
and on the
project pages of the editor modules.

As for the <font> tag from hell, I tend to remove its
toolbar controls
from TinyMCE and instead give my customers the Styles
dropdown
containing classes of the website's CSS (or a separate CSS
file). As a
bonus, this makes for much cleaner code and easier to read
texts. I
don't give them the "Edit HTML code" button
either. I'm also looking
into HTML Purifier which with its whitelist stops XSS and
creates
standards compliant code.

>From the HTML Purifier website:
"Even the most dogmatic purist, however, should
recognize that for all
its faults, prospective clients really want rich text
editors. There
are steps you can take to mitigate the associated drawbacks
of these
editors." -> http://hp.jpsba
nd.org/comparison.html

Drupal module here (beta):
http://bart.motd.be/projects/html-purifier-drupal-module