[development] Drupal's CVS policies... including 'foriegn'codein TinyMCE module?
matt at mattfarina.com
Fri May 25 02:34:51 UTC 2007
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
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.
>> On 5/24/07, Kevin Reynen <kreynen at gmail.com> wrote:
>>> In TinyMCE case, it's not just a config file. When you download
>>> from Moxicode you get lots of extra files (examples, _src.js,
>>> icons, etc). The current install process has the user download
>>> the full
>>> TinyMCE package and throw it into the TinyMCE module folder. So
>>> 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
>>> 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
>>> 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
>>> 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
>>> amount of code might be, but since there are already respected
>>> 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
More information about the development