Integration with wysiwyg module

I think this is a great ideal...........so you just have to install the plug-in for mce...or ckeditor?

give me direction...

subscribing.

I found that in order to user the syntax highlighter with the TinyMCE button plugin mentioned in the original post, I also had to install the preelementfix tinymce plugin to stop newlines getting converted to <br/> and other strange issues within <pre> tags.

For convenience to others, I wrapped the preelementfix TinyMCE plugin into a wysiwyg API extension module, so that it can be enabled on a per input format basis.

http://drupal.org/project/wysiwyg_preelementfix

Yes

Adding Libraries tag

Hi, I'm the writer of the original blog post at the top of the thread. I'm very interested in this work. I'm a little confused about the approach beng suggested. Can't we just create a new module called wysiwyg_syntaxhl that depends on wysiwyg, syntaxhighlighter, and wysiwyg_preelementfix?

Or are you (@sinsalek) suggesting adding a sub module to syntaxhighlighter?

Just to test out some theories and flex my module muscles, I created a module in the mold or mrfelton's preelement fix module. I called it wysiwyg_syntaxhl, and it works pretty good. If it's alright, I can just create a new drupal contrib module with it, unless you really want it as a sub-module to syntaxhighlighter. I have attached a tarball. It is complete, including docs, and it works on my up-to-date drupal install. It depends on wysiwyg, syntaxhighlighter, wysiwyg_preelementfix (and tinymce in the libraries directory, of course)

Actually, I modified the module slightly to more reliably get the tinymce location. This could be used on the preelementfix as well, btw. You can get the path via:

$path = wysiwyg_get_path('tinymce') . '/jscripts/tiny_mce/plugins/syntaxhl/editor_plugin.js';

for preelement, I recommend somehting similar, like

$path = wysiwyg_get_path('tinymce') . '/jscripts/tiny_mce/plugins/preelementfix/editor_plugin.js';

and modify the instructions to drop the plugin in the libraries/tinymce/... directory structure. That way the wysiwyg_preelementfix module can remain pristine for drush updating and you can keep the tinymce plugins in their proper location.

Unless anyone minds, I'd like to submit this wysiwyg_syntaxhl contribution as a new module.

well, I was a bit bored tonight so I went ahead and went the module route. Just install this:

http://drupal.org/project/wysiwyg_syntaxhl

I use the http://drupal.org/project/wysiwyg_filter as my input filter and it doesn't allow the class="brush: xyz" format. It strips out the class="..." part from the pre tag even though I allow the class name brush*

A way to solve this problem is to modify the syntaxhl plug-in to insert code in the filter format instead of using the pre tag.

Instead of:

<pre class="brush: xyz>

    ....

</pre>

insert this:

{syntaxhighlighter brush:xyz}

   ...

{/syntaxhighlighter}

with this, we may not even need preelementfix

subscribe

I'll modify it and see if it works and then report back. Also I noticed an issue, where the syntaxhl tiny plugin has a list of languages to choose from that obviously is not reading the drupal syntaxhighlighter settings. I'm not sure what we can do about that.

hmm, no, @mattyoung, it doesn't really work. For one thing, it causes tiny to just insert the literal:

{syntaxhighlighter brush: php;fontsize: 100; first-line: 1; }

...

{/syntaxhighlighter}

But tiny doesn't know how to handle that region. It actually does work initially, but then, for example, if you go back into that region and edit anything it gets all screwed up. Is it possible to get the wysiwyg_filter module guys to allow a 'brush: xyz' format?

I downloaded the wysiwyg_filter module and played around with it. Based on its current rules, you just cannot set it up to allow the type of classnames that syntaxhighlighter produces. Going the other way and using the {} type notation will break tiny, so that's out too.

The only hope is to convince the wysiwyg_filter guys to relax their restrictions on what you can specify for class names. Currently it's very restrictive:

Enter a comma separated list of rules for Class Names. Whitespaces and line-breaks are ignored. Class Names should start with a lower case letter "a-z" and can be followed by one or more lower case letters "a-z", digits "0-9", hyphens "-" and/or underscores "_". The asterisk character "*" can be used in rules to represent any number of characters from the second position of the rule. Example: "userclass*, my-font-*" are valid rules for Class Names, whereas "*class" is invalid.

You typically have something like this:

<pre class="brush: jscript;fontsize: 100; first-line: 1; ">

which means you will never be able to satisfy their filter, no matter how cleverly you place your asterisks.

I did modify their code and make it work though. Online 76 and 77 of wysiwyg_filter.module, I made it look like this:

      'validate_regexp' => '`^[*a-z.][.:-_a-z0-9?*]*$`',
      'asterisk_expansion' => '.*',

and then I just put a '*' in the Rules for Class Names box in the filter settings, and it works. Of course it bypasses the restrictions they want to place on class names.

I created an issue on the wysiwyg_filter page for this:

#647476: Relax restrictions on class names for syntaxhighlighter

I woke up this morning with an idea...it might be possible to rewrite the tinymce plugin so that it inserts a pre tag in the editor, but replaces it with the '{}' syntax upon save. On re-edit, it replace the '{}' tags with a 'pre' again.

I'll work something up and see if it works.

>it doesn't really work. For one thing, it causes tiny to just insert the literal:
>
>{syntaxhighlighter brush: php;fontsize: 100; first-line: 1; }
>
>...
>
>{/syntaxhighlighter}
>
>But tiny doesn't know how to handle that region. It actually does work initially,

Not sure why it works then not. This module's filter converts all the {syntaxhighligther ...} ... {/syntaxhighlighter} into the <pre> ... </pre>. Should just work.

#647476: Relax restrictions on class names for syntaxhighlighter:

>Things would be easier if Syntaxighighlighter in client-side was generating a macro, something that does not use HTML tags, for example [syntaxhighlighter: brush: jscript;fontsize: 100; first-line: 1;]. Then this could be expanded to HTML using a separate input format that executes after WYSIWYG Filter.

This is exactly what this module's input filter is.

>Not sure why it works then not. This module's filter converts all the {syntaxhighligther ...} ... >{/syntaxhighlighter} into the

 ... 

. Should just work.

Because once {syntaxhighligther ...}{/syntaxhighlighter} is in the tinymce editor it is HTML. Let's say I initially have this:

{syntaxhighligther ...}
<?php
 print $test;
?>
{/syntaxhighlighter}

Once it's inserted into tiny, it's HTML, so if I go into that section and add another line, like 'print $test2', it will look like this in tiny:

{syntaxhighligther ...}
<?php
 print $test2;

 print $test2;
?>
{/syntaxhighlighter}

but when the editor detaches, I will actually get a mess like this:

{syntaxhighlighter ...}
<?php
 <p>print $test2;</p>
<p>&nbsp;</p>
 <p>print $test2</p>
?>
{/syntaxhighlighter}

which will then be rendered by syntaxhighlighter and changed to a div, but that div won't contain the code you thought you were going to get, it will contain:

<?php
 <p>print $test2;</p>
<p>&nbsp;</p>
 <p>print $test2</p>
?>

While it's in the tiny Editor, it needs to actually be in a a real 'pre' element so tiny knows how to treat text inside of it. It knows nothing about what {syntaxhighlighter} means, so it just considers it html.

Anyway, I'm making progress on doing the great switcheroo, where tiny will make it a 'pre' inside the editor, and switch it to the macro version on save.

>Anyway, I'm making progress on doing the great switcheroo, where tiny will make it a 'pre' inside the editor, and switch it to the macro version on save.

Great! Looking forward to it.

ok, I've attached a new version for testing. Id it works, I'll commit the changes back to my module. Basically, now it looks for {syntaxhighlighter} blocks when it loads content. Then the plugin converts these to pre tags for use in the editor. Then when you save the node, the pre tags are converted back to {} tags.

give it a spin and let me know if it works.

I tested it and it's working great. It seems we don't need the "pre element fix" with this. If true, then one less module dependency.

The one remaining issue is the language choices are wrong. Perhaps I can do drupal_add_js() with an array of selected languages and we modify the syntaxhl plugin to use that instead of the default?

The array would be something like this:

array('human-readable-name' => 'brush-name', ...);

you read my mind, I'm doing that exact thing right now. Do you have a quick code snippet on how to get that array of readable names from your module? It would be something like this from your module:

  $path = _syntaxhighlighter_get_lib_location();

  $files = file_scan_directory($path .'/scripts', 'shBrush.*\.js');
  foreach ($files as $file) {
    $lang_options[$file->basename] = substr($file->name, 7);
  }

combined with the:

variable_get('syntaxhighlighter_enabled_languages', array('shBrushPhp
.js'))

bit.

I think we still do need preelementfix though. I tried working without it and it's a major pain in the ass. It works great if you use the plugin and insert code and then don't touch it, but then while in the editor (not the popup) if you change any of the items in your 'pre' area you get really unpredictable results that are browser dependent.

Let me know how you me to do, or you make a patch and I'll apply and make a snapshot release.

I did something like this:
Sorry, I wasn't asking you to change your module, just asking for advice on how to use your modules variables to get a proper array. No matter though, I worked something out like this:

        $languages=array();
        foreach ( variable_get('syntaxhighlighter_enabled_languages', array('shBrushPhp.js')) as $ind=>$val) {
          if ($val) {
            $languages[]=array('value' => strtolower(substr(substr($ind, 7),0,-3)), 
              'text' => substr(substr($val, 7),0,-3)
            );            
          }
        }
        $settings = array(
          'wysiwyg_syntaxhl' =>  array('languages' => $languages)
        );
      drupal_add_js($settings, 'setting');

and then in the popup window I did this:

	<script type="text/javascript">
  /*<![CDATA[*//*---->*/
  function addLanguages() {
    for (i=0; i < parent.Drupal.settings.wysiwyg_syntaxhl.languages.length;++i){
      var optn = document.createElement("OPTION");
      optn.text = parent.Drupal.settings.wysiwyg_syntaxhl.languages[i]['text'];
      optn.value = parent.Drupal.settings.wysiwyg_syntaxhl.languages[i]['value'];
      document.syntaxhl.syntaxhl_language.options.add(optn);
    }
  }
  /*--*//*]]>*/
  </script>

That seems to work pretty well. The changes will be in my dev branch soon, so feel free to give them a spin when they drop.

variable_get('syntaxhighlighter_enabled_languages', ...) is the right place to get a list of all enabled langs. I think it's probably better to declare dependency to my module in your .info.

You module will make things much more user friendly and usable to both anon and auth'ed users.

thx

It would be great if you can update your article once things are finalized.

1.1 is out and has all the updates we discussed.

http://drupal.org/project/wysiwyg_syntaxhl

Also, no additional steps are needed for the install, just put it in the modules directory and enable it.

so is my wysiwyg_preelementfix still needed with this new module?

Yes, IMO, it is and I listed it (along with syntaxhighlighter and wysiwyg) are listed as dependiencies for my module.

Without the preelementfix, the 'pre' boxes in the editor are just unusable, although I think this is browser dependent.

If you were just clicking the syntaxhl button, pasting in your code and saving, there would be no problem, but typically, you have to go into that pre element and make changes and without the fix module, every time you hit return, you get a new pre, or a nested pre, or a br or lots of other weird things.

For anonymous user, I get garbage text in the syntaxhhl dialog:

http://i6.photobucket.com/albums/y222/moyoungerman/post/Screenshot2009-1...

If I login, it's fine:

http://i6.photobucket.com/albums/y222/moyoungerman/post/Screenshot2009-1...

what could be the problem?

You can see this on my site: http://hddigitalworks.com/syntaxhighlighter-drupal-module

use the comment form and click the syntax_hl button.

hmm, not sure off the top of my head. Can you create an issue on http://drupal.org/project/wysiwyg_syntaxhl issues page for it?

#650620: Anonymous user garbage text in the syntaxhhl dialog

Please head over to http://drupal.org/project/wysiwyg_syntaxhl