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

Sean Robertson seanr at ngpsoftware.com
Fri May 25 02:41:13 UTC 2007


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

-- 
Sean Robertson
Web Developer
NGP Software, Inc.
seanr at ngpsoftware.com
(202) 686-9330
http://www.ngpsoftware.com



More information about the development mailing list