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