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

[Kevin Reynen]

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

On 5/24/07, Matthew Farina <matt at mattfarina.com> wrote:
>
> Can someone explain what would be the difference between including a
> configured TinyMCE and TinyMCE from moxiecode?  Would it just be the
> configuration file or more?
>
> I'm starting to wonder if going with a ftp/sftp approach (like
> Joomla) has wouldn't be a bad idea.  We could keep the code out or
> our repository yet have the installer pull it down and put it in the
> right place/give a simple upload window as a step with instructions
> where to download it.
>
> In the case of TinyMCE, if it's just the config file that could be
> written via this ftp/sftp functionality.
>
> And, maybe not allowing the change to CVS policy would give incentive
> to write the ftp functionality.
>
> Just some thoughts....
>
> Matt
>
> On May 24, 2007, at 6:31 PM, Sean Robertson wrote:
>
> > I would like to see a Drupal-optimized TinyMCE package.  It'd make
> > it a lot easier on me if it had standard Drupal-related plugins
> > already installed so I didn't have to do that manually for every site.
> >
> >
> >
> > Matthew Farina wrote:
> >> At this point a number of merits for both directions have come out
> >> here.  Currently the policy is to not have them in CVS.  What
> >> would it take to change that policy?
> >> On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
> >>> I had conceded to host the Drupal specific version of TinyMCE
> >>> myself, but Tao's message was interesting enough to suck me back
> >>> in to this.
> >>> Round 2... ding, ding
> >>>
> >>> Nedjo asked about the 3rd party library issue ( http://drupal.org/
> >>> node/124978), but it looks like Jeff just went ahead and uploaded
> >>> the files he wanted to use to CVS as part of the modules instead
> >>> including links and documentation for where to download the files
> >>> and how to install or configure them.
> >>>
> >>> Jeff includes unmodified? versions of jquery.js 1.1.2 and compat.
> >>> 1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0)
> >>> in jQuery_update.  The interface.js (78k) included in the
> >>> JQuery_interface is available from the developer at http://
> >>> interface.eyecon.ro/changelog
> >>>
> >>> I also found it here...
> >>>
> >>> http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/
> >>> interface.js
> >>> http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/
> >>> interface.js <http://trac.bbpress.org/browser/trunk/bb-includes/
> >>> js/jquery/interface.js>
> >>>
> >>> Ironically, you can also find the WordPress optimized version of
> >>> TinyMCE in wp-includes as well...
> >>>
> >>> http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce
> >>> <http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce>
> >>>
> >>> TinyMCE IS included as part of the WordPress "core", but as a
> >>> customized/optimized/compressed version with a small number of
> >>> plugins  ( http://trac.wordpress.org/browser/trunk/wp-includes/js/
> >>> tinymce/plugins).  By dropping  the
> >>> _src.js files and unused themes/icons, the WordPress TinyMCE is a
> >>> much smaller download.  They also include WordPress specific plug-
> >>> ins for functionality and help.  These are the types of
> >>> optimizations I'd like to be doing to TinyMCE for Drupal, but the
> >>> current CVS policy requires me to host a Drupal specific version
> >>> of TinyMCE myself.
> >>> For the TinyMCE module, it doesn't make a whole lot of sense to
> >>> put the required library in another download since the module's
> >>> sole purpose is to enable and configure the TinyMCE library, but
> >>> if other modules requiring external libraries standardized on how
> >>> the libraries are handled I'd go along for that ride.  Assuming
> >>> there are no licensing conflicts, libraries could be treated as
> >>> modules.  Library dependencies could be handled by the .info,
> >>> someone would have 'own' the security and support issues related
> >>> to the library just like maintainers (in theory) own these for
> >>> modules, and version conflicts between developers using a common
> >>> resources could be worked out the same way they are now.
> >>>
> >>> I don't know what the ramifications of this suggestion would be
> >>> for the people maintaining the CVS, but there are obviously
> >>> active developers who are frustrated by the policy and others who
> >>> are just ignoring it.
> >>>
> >>> - Kevin Reynen
> >>>
> >>>
> >>> On 5/24/07, *Tao Starbow* <starbow at citris-uc.org
> >>> <mailto:starbow at citris-uc.org>> wrote:
> >>>
> >>>
> >>>     > aps to address this concern, we could create a dedicated
> >>> module that
> >>>     > simply provides the third party library in question and
> >>> little or no
> >>>     > additional functionality as required by drupal. The the
> >>> modules
> >>>     that
> >>>     > depend on it can do just that in the info files. Avoids
> >>> duplication
> >>>     > and centralizes the management and ability to audit for
> >>> security
> >>>     > issues too boot.
> >>>
> >>>     This is the approach Jeff Robins has taken with his
> >>> jQuery_update and
> >>>     jQuery_interface modules, and I think it works very well.  This
> >>>     approach
> >>>     leverages Drupal's project versioning and dependency systems to
> >>>     keep the
> >>>     3rd party (GPL) code insync with the Drupal code, and simplifies
> >>>     instillation.
> >>>
> >>>
> >
> > --
> > Sean Robertson
> > Web Developer
> > NGP Software, Inc.
> > seanr at ngpsoftware.com
> > (202) 686-9330
> > http://www.ngpsoftware.com
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070524/1d5b2c29/attachment-0001.htm