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

Sean Robertson seanr at ngpsoftware.com
Thu May 24 22:31:13 UTC 2007

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

More information about the development mailing list