[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
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
>> I also found it here...
>> Ironically, you can also find the WordPress optimized version of
>> TinyMCE in wp-includes as well...
>> TinyMCE IS included as part of the WordPress "core", but as a
>> customized/optimized/compressed version with a small number of
>> 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
>> > 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
>> leverages Drupal's project versioning and dependency systems to
>> keep the
>> 3rd party (GPL) code insync with the Drupal code, and simplifies
NGP Software, Inc.
seanr at ngpsoftware.com
More information about the development