[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
matt at mattfarina.com
Thu May 24 22:59:09 UTC 2007
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....
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://
>>> I also found it here...
>>> interface.js <http://trac.bbpress.org/browser/trunk/bb-includes/
>>> 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 ( 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
>>> > depend on it can do just that in the info files. Avoids
>>> > and centralizes the management and ability to audit for
>>> > 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
> Sean Robertson
> Web Developer
> NGP Software, Inc.
> seanr at ngpsoftware.com
> (202) 686-9330
More information about the development