wysiwyg broken ckeditors protectedSource feature. [#775076]

I am now config the wysiwyg and ckeditor and geshifilter to working. I almost got it, while there is a problem when the ckeditor switch from source mode to rich text mode, the php code which have been protected by ckeditor still been stripped. I am sure it's should not be a fault from ckeditor, it's something wrong with wysiwyg. I have test it hard to got the reason, use the ckeditor without wysiwyg, with the same code, with the same protectedSource setting it is no problem at all.

The Code for test is list here:

<?php 
  /**
   * Implementation of hook_wysiwyg_editor_settings_alter().
   */
  function ckeditor_custom_wysiwyg_editor_settings_alter(&$settings, &$context) {
    if ($context['profile']->editor == 'ckeditor') {
      $settings['uiColor'] = '#9AB8F3';
      $settings['language'] = 'zh-cn';
    }
  }?>

Every time the wysiwyg will change the php source to

editor == 'ckeditor') {
      $settings['uiColor'] = '#9AB8F3';
      $settings['language'] = 'zh-cn';
    }
  }?&gt;

First, it remove all the source from <? ... to the first > Whenever it is closed with ?> or not, it will also change the last > to > .

I may sure the change was made from the JS side, as when I have disable javascript of my firefox, the php code is exactly as it in msyql.

My config, disable all the filter of my format, disable the Verify HTML from wysiwyg gui only keep Convert tags to styles setting,

Any help will be appreciated, I will back to the problem when I have more time on it.
Thanks

Comments

Comment #1

twod

Swedish

Sweden

commented 19 April 2010 at 10:16

Status:

Active

» Postponed (maintainer needs more info)

Wysiwyg has not enabled the protectedSource option by default (neither does CKEditor itself by default).

As we discussed in #313497-59: Allow configuration of advanced editor settings - starting from #59 - it's currently not possible to enable it via hook_wysiwyg_editor_settings_alter() because that option takes a list of regular expressions as a value. You would have to change the protectedSource setting "manually" in CKEditor's config.js for now.

Once that is done, the PHP code should not be removed by Wysiwyg core itself as it doesn't modify the contents. There is a slight chance that a "Drupal plugin" (like Teaser break) may be responsible for removing the code (since it doesn't expect PHP code when transforming the content string to and from a DOM tree).

Do you have Teaser Break, or any other plugin provided by another module, enabled?

Comment #2

wqmeng commented 19 April 2010 at 10:53

Thanks god, I just turned off of the Teaser Break, Then the problem get solved, So it should be the Tease Break plunin's problem, I am not check deep with it. Should be some regex replace problem.

I have thought it should be something wrong with wysiwyg, as I have already add the protectedSource to Ckedtior from a plugin and it does work.

So let's find what's wrong with the Teaser Break.

For The Win, Cheers.

thank you

Comment #3

twod

Swedish

Sweden

commented 19 April 2010 at 11:39

Ah ok, then I think I know what the problem is. Teaser Break currently doesn't use regular expressions to do its processing but converts the content string to a DOM and then uses jQuery's .html() method - which internally uses the .innerHTML property. Because of this, the formatting (and XHTML conformity) is messed up by the browser, and maybe it also removes the PHP code. Then it's the same cause as in #510552: Invalid XHTML: missing trailing slashes, absolute urls and uppercase tags.

I did create a patch in the above issue to make Teaser Break use regular expressions instead, but this workaround wasn't enough for other plugins which rely on having a DOM to work with. We've decided to use a different method to retrieve the contents of all the DOM nodes (an extra .xhtml() method) which may also solve this issue.

I'll leave this issue open until I can confirm that the solution to #510552: Invalid XHTML: missing trailing slashes, absolute urls and uppercase tags also fixes this issue. We've got a few "HTML to XHTML cleanup" libraries to try with and one of them seems simple enough while being able to preserve formatting, though it has a few minor bugs with selfclosing tags etc.