WYSIWYG editors considered harmful for site admins (and in general, but that's a separate thread)
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
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.
Hi, I think this is a very good idea. I know that with HTMLArea I put a value onto the indicate that this should be converted, And with jQuery it will be so easy to exclude those that have a class or something that indicate no wisiwyg editor. Also it could be used for fields that are php filtered so we know not to convert it. Gordon. Nedjo Rogers wrote:
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://drupal.org/node/81297#comment-203670
!DSPAM:1000,45f5e62577831421416041!
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.
Just for the record, I wish to point out just two or three things: 1. WYSIWYG editors are here to stay (not necessarily in core, of course) and are an absolute necessity for many customers. 2. Those customers include "no HTML spoken" administrators. 3. I repeat, administrator != programmer && administrator != person very knowledgeable about Drupal in any way outside of routine admin tasks.. 4. class Admin extends Non_Geek_User 5. Those who use WYSIWYG editors should not use full html input, but should create an adequate button set / html tag set. Also, additional js filters and/or tidy html filters should be implemented, as noted above. A concrete example just the other day, a user/administrator needed a WYSIWYG editor in order to create blocks herself (in this case to make kinds of customized blogrolls). With TinyMCE, she could upload icons and make links without knowing HTML. So even tho they are the devil's own work, they are here and are used by the countless hordes. Please do not forget that and put something prohibiting them in administration pages, should someone need that functionality. Victor Kane http://awebfactory.com.ar On 3/13/07, Karoly Negyesi <karoly@negyesi.net> wrote:
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.jpsband.org/comparison.html
Drupal module here (beta): http://bart.motd.be/projects/html-purifier-drupal-module
Excellent comments, that is the right approach. On 3/13/07, Joakim Stai <joakimstai@gmail.com> wrote:
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.jpsband.org/comparison.html
Drupal module here (beta): http://bart.motd.be/projects/html-purifier-drupal-module
On 13 Mar 2007, at 13:51, Joakim Stai wrote:
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.
Yes. WYSIWYG editors are here to stay, and it's our task to make sure they can be used securely and conveniently. I've suggested adding the input formats to the textarea form element before, so I think that the discussion/work at http://drupal.org/node/ 125315 has potential. Let's tune in and help out with that. :-) -- Dries Buytaert :: http://www.buytaert.net/
@Joakim Stai - At the agency I work for, we currently use Drupal for our site and have about 60 other sites running off of the same codebase. With all these fingers in the pie, inevitably we have several people that want to cut and paste from Microsoft Word. The HTML/XML code soup that this generates would be a nightmare without help from Moxie Code's TinyMCE filters. The problem is/was font tags creeping in. To avoid this, we wanted to use the convert_fonts_to_spans filter (see http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/convert_fonts_to_s...). In the module, admin/settings/tinymce/edit/[enter profile name here] settings supposedly have the ability to turn this filter on. However, it was incorrectly implemented in the .module file. See mlsamuelson's patch at http://drupal.org/node/126364. ejhildreth
On 3/13/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
Yes. WYSIWYG editors are here to stay, and it's our task to make sure they can be used securely and conveniently.
I'm glad to hear that! But then again, anything else would surprise me. I hope, without affecting the core too much, it will be possible to facilitate WYSIWYG implementations as much as possible.
I've suggested adding the input formats to the textarea form element before, so I think that the discussion/work at http://drupal.org/node/ 125315 has potential. Let's tune in and help out with that. :-)
I've come across the issue, will take a closer look at it. Looks interesting.. On 3/13/07, Eric Hildreth <ejhildreth@gmail.com> wrote:
The problem is/was font tags creeping in. To avoid this, we wanted to use the convert_fonts_to_spans filter (see http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/convert_fonts_to_s...).
Thanks for the tip, will definitely check it out! Instructions like these should also make it to the handbooks. And speaking of the work of the devil, Microsoft Word's HTML output certainly is.
On 3/12/07, Greg Knaddison - GVS <Greg@growingventuresolutions.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
On Mon, 12 Mar 2007 16:02:37 -0700, "Boris Mann" <boris@bryght.com> wrote:
On 3/12/07, Greg Knaddison - GVS <Greg@growingventuresolutions.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....
The "WYSIWYG devs" were clamoring for a "yes, use a WYSIWYG here" flag on textareas for weeks in the issue queue. The eventual message they received was "write a contrib that does it and all agree on it, and that will solve the problem." If it's a security risk, though, then allowing such a flag in core (we already have the collapse flag for fieldsets and the expandy-grippie flag for textareas in core) would give WYSIWYG editors exactly what they're asking for and also give them no excuse for putting a WYSIWYG editor in a "bad" place. Greg's got it right. :-) --Larry Garfield
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.
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
On 3/12/07, Boris Mann <boris@bryght.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
participants (14)
-
Boris Mann -
Dries Buytaert -
Eric Hildreth -
Gabor Hojtsy -
Gordon Heydon -
Greg Knaddison - GVS -
Joakim Stai -
Karoly Negyesi -
Kevin Reynen -
Larry Garfield -
Nedjo Rogers -
Neil Drumm -
Victor Kane -
Walt Daniels