[development] Drupal's CVS policies... including 'foriegn'codein TinyMCE module?

[Sean Robertson]

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 at 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 at ngpsoftware.com
(202) 686-9330
http://www.ngpsoftware.com