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

[Matthew Farina]

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 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
>