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@citris-uc.org <mailto:starbow@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@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com