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

Peter Wolanin pwolanin at gmail.com
Fri May 25 00:57:33 UTC 2007


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


More information about the development mailing list