When rich-text editing is enabled in the account settings and then editing a page with embedded JavaScript, the <script> and </script> tags surrounding the JavaScript get stripped. Switching off richt-text editing dynamically before submitting the page does not help as the damage has already been done.

We are running Drupal 4.7.0-beta4 with tinymce.module 1.66 2006/01/13 17:40:45.

We have set the following options:

  $init['remove_linebreaks'] = 'false';
  $init['document_base_url'] = "base_path()";

Thanks,
Bastiaan Veelo

CommentFileSizeAuthor
#19 enable_full_xhtml.patch18.89 KBharking

Comments

budda’s picture

budda
Primary language English
Location Cheshire
commented

Is the 'script' tag in your allowed HTML tags? (see filters)

veelo’s picture

veelo commented

We are using Full HTML, configured to allow inline images.

veelo’s picture

veelo commented

Note that if the editor is disabled in the account settings page, scripts work fine. So I don't think it is a Drupal filtering problem.

budda’s picture

budda
Primary language English
Location Cheshire
commented

I don't know what the javascrit pyou're inserting is for, but would it not be safer to insert a Drupal filter tag [blah] and then inject the javascript upon saving the node?

veelo’s picture

veelo commented

The javascript is for displaying a slide-show on this page.

Unfortunately I don't understand a thing about your proposal with a filter tag and injecting upon save. Can you point me to some documentation, or elaborate please?

Thanks,
Bastiaan.

budda’s picture

budda
Primary language English
Location Cheshire
commented

You'd probably have to write your own module to do it.

The adsense module is an example of a Drupal filter tag, in your node body you enter [adsense:xxx] and then upon submitting the node it inserts the required javascript.

When you edit the node it only shows the filter tag.

Check the Drupal handbook.

You might be able to use something like the keyword filter module I noticed in CVS...

Sorry I can't offer any mroe exact help.

veelo’s picture

veelo commented

OK, TinyMCE strips all elements that are not in its valid_elements list. By default it works with a reduced set, I don't know why. See option_valid_elements. The solution is to add script tags to this list. This is how I did it in Drupal 4.7.0-beta4 (I also redefined the img tag, as I need to alow the name attribute in it).

0) Assumed you use a PHPtemplate theme in themes/mytheme.

1) Create themes/mytheme/template.php if it does not exist.

2) add this function:

/**
  * Catch the theme_tinymce_theme function from tinymce.module, and reimplement it.
  */
function phptemplate_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
  // New stuff:
 
  // Keep formatting of source:
  $init['remove_linebreaks'] = "false";

  // Make embedded scripts work:
  $init['extended_valid_elements'] =
    "script[charset|defer|language|src|type]," .
    "img[align<bottom?left?middle?right?top|alt|border|class|dir<ltr?rtl|height" .
	"|hspace|id|ismap<ismap|lang|longdesc|name|onclick|ondblclick|onkeydown" .
	"|onkeypress|onkeyup|onmousedown|onmousemove|onmouseout|onmouseover" .
	"|onmouseup|src|style|title|usemap|vspace|width]";
  //
  // The rest is just pasted contents of tinymce.module:theme_tinymce_theme():
  switch ($textarea_name) {
    // Disable tinymce for these textareas
    case 'log': // book and page log
    case 'img_assist_pages':
    case 'caption': // signature
    case 'pages':
    case 'access_pages': //TinyMCE profile settings.
    case 'user_mail_welcome_body': // user config settings
    case 'user_mail_approval_body': // user config settings
    case 'user_mail_pass_body': // user config settings
    case 'synonyms': // taxonomy terms
    case 'description': // taxonomy terms
      unset($init);
      break;

    // Force the 'simple' theme for some of the smaller textareas.
    case 'signature':
    case 'site_mission':
    case 'site_footer':
    case 'site_offline_message':
    case 'page_help':
    case 'user_registration_help':
    case 'user_picture_guidelines':
      $init['theme'] = 'simple';
      foreach ($init as $k => $v) {
        if (strstr($k, 'theme_advanced_')) unset($init[$k]);
      }
      break;
  }

  // Add some extra features when using the advanced theme.
  switch ($theme_name) {
    case 'advanced':
      //$init['extended_valid_elements'] = array('a[href|target|name|title|onclick]');
      break;
  }

  // Always return $init; !!
  return $init;
}
mariagwyn’s picture

mariagwyn commented

Just wanted you to know this was very helpful. TinyMCE was stripping empty divs that I use for design elements in a page, but your code helped (with an addition or two). Of course, I don't understand it, but at least it is working/

:)
Maria

Wesley Tanaka’s picture

Wesley Tanaka commented

You could also call theme_tinymce_theme instead of duplicating it.

mariagwyn’s picture

mariagwyn commented

Wesley,
I tried the code on your post (http://ofb.net/~wtanaka/node/383)

It works, in that it allows me to have advanced/simple themes on particular textblocks. What it does not do is permit the "new stuff" section from veelo. I need it specifically for the following code:

"div[align<center?justify?left?right|class|dir<ltr?rtl|id|lang|onclick"
  "|ondblclick|onkeydown|onkeypress|onkeyup|onmousedown|onmousemove"
  "|onmouseout|onmouseover|onmouseup|style|title],"

How do I include this? In my template.php? In a specific file in tinymce? I am trying to do minimal editing of tinymce since I don't have a lot of time for this, and I don't want things to get overwritten everytime I upgrade. so, for the sake of neatness, I would certainly prefer to call theme_tiny_mce, and in template.php, override with the specific things I need to include, such as the div or img tags. How do I do this? Where do I put it? While I can find the documentation on overriding, I can't tell where to actually put or modify it.
thanks,
Maria

Wesley Tanaka’s picture

Wesley Tanaka commented

All I did was shorten the code in comment #7.

I'm guessing(!) that in your case, you might want to replace valid_elements with extended_valid_elements and replace '*[*]' with that code you just quoted in your comment?

I haven't looked up what extended_valid_elements does, so I don't really know.

whereisian’s picture

whereisian commented

Veelo nailed it in comment 7. That snippet has been very valuable. Having an extra settings area so that this could be configured in the gui would be nice.

mariagwyn’s picture

mariagwyn commented

Wesley,

Where do I activate the extended valid elements? That is what I can't find. I see the doc folder, but I am not sure how I actually call it.

Thanks,
Maria

Wesley Tanaka’s picture

Wesley Tanaka commented

After you have either phptemplate_tinymce_theme or THEMENAME_tinymce_theme defined properly in your template.php file, just drop the template.php file in your theme directory, and whatever settings you've set in your _tinymce_theme function (including extended_valid_elements) should be applied to any future page loads.

ñull’s picture

ñull commented

I experience the same thing with , also stripped by TinyMCE. How would you add that tag to the extended valid elements?

kreynen’s picture

kreynen commented
Assigned: Unassigned » kreynen
Priority: Normal » Critical
harking’s picture

harking commented

It might be better to add support for the whole xhtml spec as listed here:
http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements

This would allow TinyMCE to work as a standard editor, and then let Drupal strip out what it does not want. Currently having the stripping occur in two places causes much confusion.

In addition to this change, the extended_valid_attribute variables in plugin_reg.php would need to be removed as they remove some extra attributes which are useful. (specifically the 'style' attribute and the id attribute).

kreynen’s picture

kreynen commented

TinyMCE is licensed as LGPL, so legally it can be included in a GPL distribution. Unfortunately Drupal's CVS maintainers won't allow us to distribute a Drupal customized version of the TinyMCE code with the module.

http://groups.drupal.org/node/3364#comment-12473

There is new version of WYSIWYG code coming soon from Moxiecode that would only require 17K of third party code in Drupal's CVS to activate the base functionality. I asked about including that in the module, but was told no to that request as well. Several developers have simply started ignoring the CVS policy. If you take even a quick look at the Lulabot's Top 40 modules, you'll find third part code in several of them...

40. XML SiteMap - http://drupal.org/project/gsitemap
- includes gss.xml (12K) found at http://sourceforge.net/projects/gstoolbox

39. Location - http://drupal.org/project/location
- includes earth.inc (6K) by Ka-Ping Yee http://www.zjlfj.gov.cn/uploadimg/2007416/up1179247864278.php?action=vie...

36. Porter Stemmer - http://drupal.org/project/porterstemmer
- includes the PHP implementation of Porter Stemmer by Richard Heyes available at http://www.tartarus.org/martin/PorterStemmer/php.txt

16. Audio - http://drupal.org/project/audio
- includes XSPF Flash player (139K) found at http://musicplayer.sourceforge.net/

There is also Jeff Robinson's JQuery Update that still includes versions of jquery.js 1.1.2 and compat.1.0.js.

Nedjo suggested some changes to the third party code policy, but nothing has come of that AFAIK. Until the rules about third party code in Drupal's CVS are relaxed, all WYSIWYG modules that require third party code will be a two step install process.

Bryght has offered to host the version control for the module outside of Drupal's CVS, but that doesn't include the automated downloadable build on change functionality and issue tracking you get hosting your module development on Drupal.

Hopefully this will get resolved before the major changes to TinyMCE are released. The current version available from Moxiecode could be better (and is in many installs), but it could get much worse for Drupal users if Moxiecode release a version of TinyMCE that conflicts with Drupal again.

harking’s picture

harking commented
StatusFileSize
new enable_full_xhtml.patch18.89 KB

Patch to enable all xhtml elements and disable broken extended_valid_elements for anyone who wants it.

AdrianB’s picture

AdrianB commented

@#18

As I've been following the issues for TinyMCE module and the discussions in Drupal development mailing list I can fully understand your frustration kreynen, this module would be so much easier to support if we were allowed to put the code in the CVS. And TinyMCE is such an important module for many projects so it would in the end make Drupal a better platform. This is one area where WordPress really understands the needs of the users better than Drupal (since WordPress comes bundled with TinyMCE).

kalin9’s picture

kalin9 commented

THANK YOU VERY MUCH!

this is EXCACTLY! what I needed.

Basically just enabling full xhtml in this manner. I think this patch should be included in the distrib so it's right there if one wishes to apply it, either that or if someone has time code in a solution.

thanks again for sharing this

mupsi’s picture

mupsi
she/her
commented
Issue summary: View changes
Status: Active » Closed (outdated)