It could happen in a contributed module, but mainly I see relying on external code as a bad idea. This is a really big complaint from end users that I would very much like to see addressed and I'm not sure the current 'download someone else's code' approach is sufficient. Matthew Farina wrote:
With the code freeze a matter of days away I don't see a WYSIWYG editor in core for D6 so the immediate path forward would be something else.
On May 24, 2007, at 10:29 PM, Sean Robertson wrote:
To be perfectly honest, I think what we really need here is a Drupal-specific WYSIWYG editor. Maybe we can reuse some Tiny6MCE code, but ultimately, I think we'll do better when there is a WYSIWYG editor in core.
Peter Wolanin wrote:
I think Kevin makes a compelling case. To me, the process of installing TinyMCE is real a pain, and I think having such a Drupal-customized version in CVS makes perfect sense in order to take advantage of the packaging, and to use CVS for tracking of the files changed, etc. -Peter On 5/24/07, Kevin Reynen <kreynen@gmail.com> wrote:
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves.
After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks!
Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense.
The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml).
The question isn't am I going to provide a Drupal friendly version of TinyMCE.
I am.
The only question is where will Drupal users interested in TinyMCE downlaod that version from?
I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure.
If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame?
The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change.
- Kevin
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com