WP-GeSHi-Highlight

A WordPress plugin by Jan-Philip Gehrcke; featuring:

  • Syntax highlighting for many languages (based on GeSHi).
  • Line numbers. Code-number displacements never occur!
  • Extremely simple to use. If desired, styles are highly&easily configurable.
  • Styles-per-block: each code block on a single web page can get its own style.
  • High performance.
  • Clean, small and valid (X)HTML output.
  • Clean and well documented source code.

Download current version @ WordPress plugin page
Examples
Usage
FAQ
Changelog

Bugs / feature requests / suggestions? Write to jgehrcke@googlemail.com

Examples

What follows is a snippet of the source code of this plugin. The code block is configured with lang="php" and line="1". The block is styled by the default style file wp-geshi-highlight.css:

  1. function wp_geshi_filter_and_replace_code_snippets() {
  2.     global $wp_query;
  3.     // Iterate over all posts in this query.
  4.     foreach ($wp_query->posts as $post) {
  5.         // Extract code snippets from the content. Replace them.
  6.         $post->post_content = wp_geshi_filter_replace_code($post->post_content);
  7.         if (is_single()) {
  8.             $comments_array = get_approved_comments($post->ID);
  9.             // Iterate over all approved comments belonging to this post.
  10.             // Filter them, too.
  11.             foreach ($comments_array as $comment) {
  12.                 $comment->comment_content = wp_geshi_filter_replace_code(
  13.                     $comment->comment_content);
  14.                 }
  15.             }
  16.         }
  17.     }

Okay, now let us have a look at a line from a shell script. In this case, the code block is configured with lang="bash". This time, we use a different style, via cssfile="another_style":

$ dd if=/dev/zero of=image.ext3 bs=1M count=10000 oflag=append conv=notrunc

In the example above, the WP-GeSHi-Highlight looks for another_style.css on the server and finds it. What follows is the content of another_style.css, using pure GeSHi styling, activated via lang="css" and cssfile="none" options:

.another_style {
  font-size: 12px;
  line-height: 13px;
  background-color: #EFEFF7;
  border-top: 1px solid silver;
  border-bottom: 1px solid silver;
  padding-left: 5px;
  }

I have tested these examples on Windows 7 on the following browsers: Firefox 3.6, Internet Explorer 8, Chrome 6, Opera 10.63.
Please let me know if you encounter any problems on other browsers, especially with the default css style which is kind of challenging (and therefore not looking optimal — but still good! — on e.g. IE8).

Usage

Write your post/page in the raw HTML editor. The general syntax for highlighting your code then is <pre arguments>CODE</pre>.

The required argument is:

  • lang="languagestring": allowed values are listed here.

Optional arguments are:

  • line="1": enables line numbering. Select the start number? See FAQ.
  • cssfile="string": selects a CSS file to style this code block. Allowed values:
    • default: if you do not set this at all, wp-geshi-highlight.css styles your code block.
    • none: all block styling is omitted. The code is still highlighted by GeSHi.
    • filename: If the file filename.css exists in the plugin directory, it is used to style the code block. Hence, if you place another_style.css on your server in the plugin directory, you can use it by setting cssfile="another_style".
  • escaped="true": the code is run through PHP’s htmlspecialchars_decode().


How to apply your own styles
Consider using the cssfile="another_style" option. Then, two things happen:

  • WP-GeSHi-Highlight puts the following structure around the HTML code generated by GeSHi:

    <div class="another_style-wrap5">
    <div class="another_style-wrap4">
        <div class="another_style-wrap3">
            <div class="another_style-wrap2">
                <div class="another_style-wrap">
                    <div class="another_style">
                        HTML code generated by GeSHi
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

    As you can see, the names of the six CSS classes depend on the value given to cssfile.

  • WP-GeSHi-Highlight looks for another_style.css in WP-GeSHi-Highlight’s plugin directory. If it is found, it is included in the HTML header of your website. Hence, you’ve plenty of room to style your code block within another_style.css, using the six different CSS classes.


FAQ

Can I change the starting line number?
Yes, try e.g. line="13". But this breaks XHTML strict compliance.

70 comments to WP-GeSHi-Highlight

  • Uli
    January 6, 2011 at 02:07 · Reply

    Hello,

    when using the Plugin in Version 1.0.2 on WordPress 3.1 with Theme Arras, the comments on the articles are not showing up. With 1.0.1-beta it works without changing anything else.

    Best Regards,
    Uli

    • Jan-Philip Gehrcke
      January 6, 2011 at 12:23 · Reply

      I am very sorry for this big one. Argh. I did my tests, but obviously I performed them much to briefly. Sorry! And thank you very very much for reporting this!

      I just uploaded version 1.0.3 which fixes this problem.

      Jan-Philip

  • Uli
    January 7, 2011 at 01:12 · Reply

    Thanks, that fixed it!

    Thanks for the plugin! I have another thing for you ;) When having the same type of sourcecode on the same page, the CSS for the highlighting is generated over and over again in the sourcecode although it’s completely identical (e.g. .bash is definied 10 times if pre lang=”bash” is used 10 times in the post). Would it be possible to push this only once to the output?

    Thanks in advance!

    Best Regards,
    Uli

    • Jan-Philip Gehrcke
      January 7, 2011 at 01:22 · Reply

      Hello again :-)

      Yes, I know about this and it makes me feel somehow uncomfortable, too. The reason is that every code block is processed individually, without looking to the left or to the right. Until now I thought about it like this: more intelligence requires more effort — which affects the performance for every single page request containing code to highlight negatively. This should be the case. To be sure, I have to look deeper into GeSHi again. Maybe there is some way without losing performance.

      So, yeah… I have some very vague ideas how to implement more intelligence to prohibit duplicate pieces of CSS code. If I have time, I will check it out and see how much performance this actually costs. Then, I’ll make some decision :-)

      Thanks for your comment!

      • Jan-Philip Gehrcke
        January 12, 2011 at 21:15 · Reply

        Uli,

        I just modified the plugin in a way, so that CSS code for one specific language is only printed once, but then entirely without further optimization adjusted to your actual piece of code. This way, the CSS code can be used for other code blocks using the same language on the same page, too. Hence, duplicate code output is prevented.

        Let me show it to you here :-)

        find . -name "rofl" | grep lol
        ls -ahl
        import os
        for foo in bar:
    print [a.stfu for a in foo if foo in bar]
        • Uli
          January 14, 2011 at 11:00 · Reply

          Hello Jan-Philip,

          now it’s perfect :) That reduced the size of some of my pages a lot as i used many code examples :)

          Thanks for the great support!

          Best Regards,
          Uli

  • Jesse Bye
    January 7, 2011 at 23:20 · Reply

    Hi Jan-Philip,
    I would really like to use your plugin, but for some reason I’m unable to get it running on my WP 3.0.4 installation. I added and activated the plugin, but when I add the lang=”" argument to some code, it doesn’t get formatted. On my example page, you can see that neither the CSS or JS get added to the header. Am I missing something? Is there more that I need to do to get it running besides installing and activating it?

    Thank you so much for your hard work and help.

    • Jan-Philip Gehrcke
      January 9, 2011 at 10:54 · Reply

      Hey Jesse,

      sorry for the late reply. It’s difficult to diagnose the problem remotely. I assume you’re not using the visual editor for your posts and it seems that the HTML you’re writing goes to the output without further filtering. My first guess ist that there might be an incompatibility with another plugin you are using.

      Could you take this approach and see if you find an incompatibility by deactivating this or that plugin?

      Let’s see where this goes.. :-)

  • Jesse Bye
    January 10, 2011 at 07:18 · Reply

    Thanks for your reply! I disabled all the other plugins I was using (Akismet, Lightbox Gallery, and WordPress.com stats), but no change, the plugin still doesn’t show up. As you’ve probably noticed, I’m using a very slightly modified version of Twenty Ten. However, I did try another theme and still the same problem. Everything else is pretty much standard, just a vanilla WP installation with no modifications.

    If it would help you diagnose things, I could setup an admin account for you so you could login and look at things for yourself. Just let me know if that’s something you would like to do.

    Thanks again for your help.

    • Jan-Philip Gehrcke
      January 10, 2011 at 15:36 · Reply

      Jesse,

      as I have to get down to this problem, I really appreciate your offer. I hope this helps. Not everybody would do this :)

      Would you mind to send me an email to jgehrcke@googlemail.com with further instructions? I think I won’t manage to look into this before the end of the week, but better late than never.

      Thank you so much,

      Jan-Philip

    • Jan-Philip Gehrcke
      January 10, 2011 at 17:35 · Reply

      I just looked through your HTML output again and saw this:

      <pre><code lang="bash" line="1">...</ code></ pre>

      If you have really typed it like this, then the solution is very easy :) Get rid of the needless code tag and use the plugin like

      <pre lang="bash" line="1">...</ pre>

      instead (without the additional space I included here). Let me know if this does it :)

      • Jesse Bye
        January 10, 2011 at 22:07 · Reply

        Aha! That was the problem! I didn’t read your instructions closely enough to see that you said “pre” instead of “code”. Once I wrapped the code in just a pre tag, it worked exactly as expected. Thank you so much for your assistance!

        One thing I noticed now that its working is a little glitch in the styling of line numbers — the numbers are cut off (on the left), and all the lines have too much space between them (see the example page again). Any ideas?

        • Jan-Philip Gehrcke
          January 11, 2011 at 00:13 · Reply

          Good, then issue 1 is solved :)

          Regarding the “optical” problems, there is some conflict between the CSS of your theme and the standard CSS of WP-GeSHi-Highlight. Your theme styles pre and ol generally, which overrides the styles of the plugin. I am not sure what I can do to avoid such things in the future. But for now, you definitely can adjust these two points:

          In the style.css of your WordPress theme, change around line 486 to

          #content p, #content ul, #content ol, #content dd, #content pre, #content hr {margin-bottom: 0;}

          And change around line 277 to

          ol {list-style: decimal outside none; margin: 0 0 18px 2.5em; }

          I found this using the “Firebug” plugin for Firefox, where you can edit CSS options very conveniently and see their effect in real time. You can try it out too and make it even better looking :)

          Perhaps you’ll even find a way of changing the standard CSS code of WP-GeSHi-Highlight to make things look good again, so that you don’t have to change the CSS of your theme. In this case, please let me know how you made it :)

  • Nick
    January 11, 2011 at 03:00 · Reply

    Love this plugin. But I notice that if I add xml to a post (inside a ‘pre’ block) then switch to the visual editor, the xml I just wrote gets severely truncated. I don’t know if the wordpress visual editor just doesn’t “like” xml code or if this has something to do with your plugin, but I was curious to get your input on the matter. Thanks!

    • Jan-Philip Gehrcke
      January 11, 2011 at 09:55 · Reply

      Hey Nick,

      hope you don’t mind that I modified your comment here :-)

      This is likely because the visual editor is simply not suitable for writing content on the “code level”. It creates HTML code itself in the output, so it doesn’t like HTML-like code (e.g. XML) in the input.

      I think that the issue you’re experiencing will happen even without my plugin.

      Maybe I didn’t state this clearly enough, but for using WP-GeSHi-Highlight and other plugins like this (that require writing code with <> letters), you should never use the visual editor.

      Within my WordPress installation, I even disabled the visual editor at all :-) To do this, see e.g. http://www.themelab.com/2008/05/17/how-to-get-rid-of-the-wordpress-visual-editor/

      Take this chance to learn some HTML! You will not regret.

  • Nick
    January 11, 2011 at 21:13 · Reply

    Ah, okay. Yeah, I kinda figured that it wasn’t your plugin, but yours is the first syntax highlighter I’ve used so I wasn’t sure. Thanks for the response!

    And thanks for that link. But for some things, the visual editor is just easier. :)

  • Alejandro Palacios
    February 12, 2011 at 03:53 · Reply

    Thanks a lot for sharing this beautiful plugin Jan.

    2 questions:

    1) Within WordPress, can i change the height of the frame where the code is displayed ?
    2) Is there a download for non-Wordpress users who want to use it in their websites ?

    thanks again !

    • Jan-Philip Gehrcke
      February 14, 2011 at 13:18 · Reply

      Hello Alejandro and Tim,

      thanks for using the plugin :-)

      The short answer for both of your questions is: 1) no and yes 2) no.

      The long answers:

      ad 1)
      The height of the ‘code box’ is chosen dynamically by the browser based on the height of the content and some static padding (top and bottom), which is defined via CSS code. You can change this CSS code either within the default CSS file wp-geshi-highlight.css or within the CSS file you are using. The padding you set there then is applied to all your code blocks.

      Do you think that being able to set this (top/bottom)-padding in a per-block-fashion via e.g. pre lang="x" padding="17px" is desired? Would definitely make some work to implement and, currently, I don’t see the huge benefit :)

      ad 2)
      This is a much too general question. As this is a WordPress plugin, the code of this plugin is adjusted to WordPress. So you cannot ‘simply’ apply this plugin to ‘other websites’. But, of course, there are ways to achieve syntax highlighting in the same fashion as this plugin does, even on non WordPress-based websites. Just tell me more about your case.

  • Roshan
    February 20, 2011 at 09:21 · Reply

    Hi Jan,

    I just started using your plugin. Is there some way that I can add keywords to code under a particular “pre” tag so that they get highlighted correctly? Lets say I am writing a blog entry about a particular shell command and “pre lang=”bash”" does not highlight this command name by default, is there someway that I can ask it to?

    Similarly, can I remove keywords?

    Thanks in advance,
    Roshan

    (Sorry about the last comment being completely unreadable – should have known better than to put actual “pre” tags in there)

    • Jan-Philip Gehrcke
      February 21, 2011 at 15:52 · Reply

      Hello Roshan :)

      GeSHi, the backend highlighting engine I am using in the plugin, allows for adding/removing keywords. Good news so far. Now, I see two possible ways to accomplish what you want.

      1) Dirty, but maybe fastest way for you for now: Look at http://qbnz.com/highlighter/geshi-doc.html#language-files to see how to define a language file. On your server, go to your plugins/wp-geshi-highlight/geshi/geshi directory. Regarding bash, you could copy bash.php to bash_custom.php and add your own keywords there. This is not exactly what you asked for, because it would work ‘semi-globally’, wherever you then use pre lang="bash_custom"… but it works :)

      2) I definitely see some way to realize exactly what you asked for: enable more arguments for the pre tag and forward them to the GeSHi API to add/remove keywords to specific keyword groups on the single code-block level. I could even think of let the user define new keyword groups. But this has to be done very carefully and definitely requires some time to accomplish and test. I don’t know if I can do this at the moment…

      So please, tell me if you’re lucky with solution (1). If not, I will have to see what I can do :)

      Jan-Philip

  • Roshan
    February 28, 2011 at 00:04 · Reply

    Hi Jan-Philip,

    Thanks for your reply. I was able to create a custom bash.php as you suggested and this does solve my problem.

    However like you say, it would be better to configure this in the body of the post. I am afraid I will quickly accumulate a large number of these custom files and that I will lose settings like this every time I make changes to the blog, reinstall the plugin etc. I have to take care to remember and back these up.

    It would indeed be good if you could do this inline, or support some sort of post-level tag where these can be configured, such that they don’t have to be repeated for each code snippet within that post.

    Thanks again,
    Roshan

    ps. Do consider enabling “Comment Reply Notification” for your blog here. That way I would have known as soon as you had replied.

    • Jan-Philip Gehrcke
      March 4, 2011 at 12:25 · Reply

      Hey Roshan,

      it’s good to have such suggestions. I definitely consider to implement what you propose. However, it will need time, because at the moment there are several entirely different things for me to do — with higher priority.

      I just installed the comment reply notification plugin, so hopefully you’ll get an email now :-)

      Jan-Philip

      • Roshan
        March 4, 2011 at 16:55 · Reply

        I did get your reply email. Thanks :)

        • Jan-Philip Gehrcke
          March 11, 2011 at 18:25 · Reply

          Roshan,

          strict implementation of the add_keyword, remove_keyword, add_keyword_group, and remove_keyword_group methods allows the user to provide tons of parameters (indices, words, colors, …). I do not like doing this inline within the PRE tag, because there data cannot be structured properly. I think using some ini-file format would be a more appropriate solution. Hence, I’m thinking of something like this:

          [add_keyword]
key = 1
word = rofl
 
[add_keyword]
key = 5
word = ugaga
 
[add_keyword_group]
key = 1
styles = ...
case_sensitive = ...
word1 =
word2 =
...

          Such an “ini-string” is easy to create for the user and easy to parse from PHP. But how to provide this ini-string? I see two ways:

          1) Introducing a new “keywordcfgfile” argument to the PRE tag. There, you could point to an ini-file on your server, which then is read and parsed.
          2) Introducing a post-level start and end marker (like “–KEYWORD_DEF_START–” and “–KEYWORD_DEF_END–”), so that this ini-string could be provided at the beginning of the post.

          What do you think?

          Jan-Philip

  • Peter jung
    March 1, 2011 at 22:30 · Reply

    Wondering what to do when the code itself contains
    open and closing PRE tags. What do you recommend?
    Peter

    • Jan-Philip Gehrcke
      March 4, 2011 at 12:30 · Reply

      Peter,

      this question drove me nuts for one day, where I wanted to find an easy way to get around this problem. There of course must be an intelligent solution. I did not investigate this deeply and, hence, did not find it yet. But this would mean a big rewrite, for sure — or I don’t see the obvious ;-)

      So, at the moment, you definitely must not use closing pre-tags within a code block at all. I’m sorry.

      Hopefully, I’ll come up with a more intelligent parser one day.

      • Igor D.
        March 6, 2011 at 23:50 · Reply

        Please do not remove PRE tags if you want to be compliant with HTML specification. You can use CODE tags inside PRE (not the other way around). I just tested this with GeSHi and WP-GeSHi-Highlight and it’s working perfetly :)

        • Jan-Philip Gehrcke
          March 8, 2011 at 11:21 · Reply

          Thanks for your opinion, Igor. Things are not perfect. I understand people trying to present code including PRE tags. And the only dirty solution there is so far, is not to use closing pre tags in the standard way. At the moment, you could e.g. insert a space between slash and pre:

          <pre></ pre>
    • Jan-Philip Gehrcke
      July 1, 2011 at 16:14 · Reply

      The obvious solution is so obvious… :D

      In your “code source” please use HTML escape sequences. At the same time, use the escaped="true" option in the corresponding pre tag. To demonstrate this, I’ll show you the same code block two times. Once without escaped="true" and once with.

      Without:

      &lt;pre lang="text"&gt;
&lt;/pre&gt;

      With:

      <pre lang="text">
</pre>
  • Igor D.
    March 6, 2011 at 22:50 · Reply

    Is there any way we can remove another_style-wrap 2,3,4,5 without changing plugin source? I did that to simplify style and created JQuery script to “show source”. You can see it on my website.

    • Jan-Philip Gehrcke
      March 8, 2011 at 10:53 · Reply

      Igor,

      the cssfile=none option removes too much, yes? You want to keep

      <div class="another_style-wrap">
    <div class="another_style">
...

      right?

      Currently, you can only do this within the source, as you did. Do you think I should introduce a parameter to change this behavior? In which way would you prefer to define this? Would this be something other users need, too?

      Thanks for your input,

      Jan-Philip

      • Igor D.
        March 9, 2011 at 03:50 · Reply

        For myself I wanted to simplify things so it is easier to make “show source” with pure JQuery/HTML (no PHP solution). For others I am not sure. I can achieve all stylings with just one wrapper and for the shadows I need just one DIV. I don’t mind changing source – guess other users should also vote on this :)

  • Roshan
    March 11, 2011 at 20:46 · Reply

    I like the idea of having a post level tag. A couple of reasons for this:

    1) Usually this sort of per-post configuration is small.

    For larger configurations, its perfectly ok to ask people to go create a custom format php (like you had originally asked me to do with bash.php.) There is no advantage to you duplicating that functionality and having to maintain all that code.

    For an example of a small configuration take a look at my post about this tool called hg-gateway. The only keywords I needed to add were “hg-gateway” along with its subcommands.
    http://parametricity.net/b/hg-gateway

    2) More importantly the custom configuration of a post will be saved and tracked along with the post itself rather than be stored on random locations on the server.

    —

    A few more thoughts:

    1) The syntax for the per post extension could be done in a more
    HTML friendly manner. For example, enclose the ini format in HTML comments so that someday if your plugin stops working, the post is still readable and the ini formatting stays hidden.

    2) You could still add extensions to the pre tag. I agree with your concern that this quickly gets ugly for large confirgurations, but for small ones, it should be simple. You can use the same naming conventions as your ini format. For example you could have the tags “add_keyword.word=” and “add_keyword.word=”. Btw wouldn’t it be better have:

    [keywords]
    level1=”word1,word2″
    level2=”word3″

  • RunTimeWorld
    March 17, 2011 at 14:27 · Reply

    Your plugin rocks! Just opened my blog and tested it, thanks a lot and keep up the good work!

  • Doug Weathers
    March 21, 2011 at 21:13 · Reply

    Hi,

    Thanks for the great plugin!

    I have a question.

    I don’t like how the default line numbering feature looks. Is there a way to get more of the GeSHi line numbering options, like the “fancy” version?

    For an example of what it looks like on my site, see

    http://www.gdunge.com/downloads/geshi-test

    Thanks again!

    - Doug

    • Jan-Philip Gehrcke
      March 22, 2011 at 00:08 · Reply

      Hey Doug,

      1) Regarding the line spacing, your WordPress theme screws up the default PRE style. See what it looks like on this page here:
      http://gehrcke.de/wp-geshi-highlight/#examples

      Your theme sets a huge lineheight and a huge margin-bottom. Get yourself a plugin for live-editing styles in your browser (like Firebug for Firefox) and change the responsible parts in your style.css. In your case, it’s around lines 470-480..:

      #content pre, #content kbd, #content tt, #content var {
    font-size: 15px;
    line-height: 21px;
}
style.css (Zeile 484)
#content p, #content ul, #content ol, #content dd, #content pre, #content hr {
    margin-bottom: 24px;
}

      A few comments above, another guy had similar problems and solved them as proposed: http://gehrcke.de/wp-geshi-highlight/comment-page-1/#comment-5376
      If you get your styling properly, your blog post about the “bad look” remains abundant :-) On a side note, there is no way to remove the dots, because I told GeSHi to use an ordered list to create line numbers. And browsers typically use numbers and dots for ordered lists.

      2) What do you mean by “more of line numbering options”? There is only “fancy” or is there more? In case of “fancy”, if you insist, I could introduce a new argument within the next version to enable “fancy” look… but I find that this is a needless feature :-) Convince me why people need it :)

      Thanks for your question and suggestion and I’m happy to read your answer ;)

  • Doug Weathers
    March 22, 2011 at 08:48 · Reply

    Thanks for the quick reply!

    I did some more looking around and found that the SyntaxHighlighter plugin (used on the WordPress.com site) looks more like what I want to see.

    It’s less efficient and uses Javascript, but for now it’s the best-looking solution. I’ll revisit this issue if it becomes a problem.

    You can see how SyntaxHighlighter looks on my blog at http://www.gdunge.com/2011/03/22/playing-with-pi.

  • Dennis
    April 3, 2011 at 14:43 · Reply

    Hi Jan-Philip,

    vielen Dank für dieses Plugin. Eine echte Alternative. Sobald ich genug Erfahrungen gesammelt habe, gibts einen Review ;)

  • Laszló Tatai
    April 4, 2011 at 13:26 · Reply

    Now here :

    Here my code :

    pre lang=”html4strict” line=”1″
    html
    head
    /head
    body
    /pre
    pre lang=”cpp” line=”5″

    /pre
    pre lang=”html4strict” line=”1″
    /body
    /html/pre
    /p

    • Jan-Philip Gehrcke
      July 1, 2011 at 16:08 · Reply

      Akismet/WordPress seem to apply quite strict filters on comment “code” provided by non-registered users. I recommend to use HTML escape sequences and the option escaped=true.
      Use the following code:

      &gt;
&lt;

      inbetween

      <pre lang="text" escaped="true">

      and

      </pre>

      It works :)
      –>

      >
<
  • tiaurus
    June 27, 2011 at 00:14 · Reply

    Unfortunately, this plugin also does not allow subscribers to comment embed code – it is cut. For example, the subscriber inserts the code: http://codex.wordpress.org/Function_Reference/get_currentuserinfo
    and obtained:

    user_login . "\n";
      echo 'User email: ' . $current_user-&gt;user_email . "\n";
      echo 'User first name: ' . $current_user-&gt;user_firstname . "\n";
      echo 'User last name: ' . $current_user-&gt;user_lastname . "\n";
      echo 'User display name: ' . $current_user-&gt;display_name . "\n";
      echo 'User ID: ' . $current_user-&gt;ID . "\n";
?&gt;
    • Jan-Philip Gehrcke
      July 1, 2011 at 15:27 · Reply

      Hello!

      Sorry for the late reply. In fact, only non-registered users experience this problem and it seems it is either a filter by Akismet or WordPress. Anyway, it can be solved by
      1) using the HTML escape sequences &lt; and &gt; in the code block
      2) using the option escaped=true

      Do it like that:

      <pre lang="php" escaped="true">
    [your php code including HTML escape sequences, see below]
</pre>

      With the PHP code looking like:

      &lt;?php global $current_user;
      get_currentuserinfo();
?&gt;

      The result is:

      <?php global $current_user;
      get_currentuserinfo();
?>

      escaped="true" translates HTML escape sequences back to their special characters. So, if you experience problems like that it is not specific to this plugin. “Bad” character combinations, that could inject malicious code to the website, are filtered out… in all these cases it is a very good idea for you/your users to enter the HTML escape sequences &gt; and &lt; directly into the pre block.

  • Gregor
    July 21, 2011 at 11:44 · Reply

    Hey, danke für das Plugin. Funktionert auf Anhieb besser als das alte WP-Syntax. Eine Frage: mit GeSHi kann man ja auch relativ simpel einzelne Zeilen hervorheben. Super-praktisch in Tutorials u.ä. Soweit ich sehe, hast du das noch nicht in dein Plugin übernommen.

    <pre lang="JavaScript" line="1" hightlight="2,4,8-9">
code
</pre>

    Wäre super wenn du das noch einbauen könntest. :)

    Gruß,
    Gregor

    • Jan-Philip Gehrcke
      July 28, 2011 at 11:23 · Reply

      Hey Gregor,

      I’m answering in English, so that everyone is able to follow :) Also, I’ve merged your two comments and I hope you are fine with that.

      Enabling highlighting is a very good suggestion! I will look into that as far as I find the motivation and time. It’s just that there is a lot of stuff at the moment with higher priority than working on this plugin (e.g. my PhD project).

      It will happen… and don’t hesitate bothering me again if it is really important for you :-)

      Jan-Philip

  • Dan
    July 22, 2011 at 05:36 · Reply

    Any chance you update the plugin to support markdown for editing text entries?

    • Jan-Philip Gehrcke
      July 28, 2011 at 11:30 · Reply

      Dan,

      I think a syntax highlighting plugin should not necessarily support something like markdown or restructured text. However, you are right and there should definitely be some plugin out there implementing these kinds of things.

      I would suggest searching the web for “wordpress + restructured text” or “wordpress + markdown” and then looking into something like this.

      JP

  • Linux Rawkstar
    August 20, 2011 at 17:07 · Reply

    Where’s the “donate” button? Let me show my thanks by providing you with a small token of my gratitude.

  • Glen
    September 22, 2011 at 04:30 · Reply

    When CSharp code is rendered, the tab spacing is 8 instead of 4. Any ideas?

    • Jan-Philip Gehrcke
      September 22, 2011 at 09:16 · Reply

      Since WP-GeSHi-Highlight is using the pre-method, tabstops are rendered by your browser — there is nothing GeSHi can do for you.

      But there is something else…: maybe you know that there is a philosophical war between people fighting for tab indents in code (\t characters) vs. people saying that spaces are the one and only. I am one of the latter ones. So, if you like being able to define the “optical characteristics” of your code for every single displaying device or editor, then just use space-based indentation. Then, no ambiguity is left.

      JP

  • Jez
    September 23, 2011 at 14:35 · Reply

    I have to say I think this code editors very good, first one I’ve used but I have to say it’s very good indeed.

    Very well done also with regards to anyone not wanting to do HTML instead preferring to use the Visual Editor (WYSIWYG), why do coding? That’s my opinion anyways, I mean when I was at University I took about a week of just constant HTML editing to get myself used to the markup, one of my hates is when people call HTML and indeed CSS coding when it’s not coding at all it’s just presentation and markup, the only logic than can be used is when you want to use hacks to override settings if browser can’t display what you want.

    I mean I never use anything like Dreamweaver or anything like that prefer to keep my HTML knowledgeable to myself where ever possible, just a personal feeling though, one of the apps I use for syntax highlighting is Notepad++ used to use Notepad2 but don’t like using that anymore.

    But I am no visual designer I am a web developer so I stick to coding myself, doing a TCP network series of tutorials in integrating Flash as a multiplayer game format for TCP networks, so this code highlighters really good to illustrate what I want.

  • Carina Zona
    September 24, 2011 at 00:40 · Reply

    The plugin’s css file, wp-geshi-highlight.css, does not seem to be registered with theme editor. I’ve tried activating various different themes to see if it’s a theme itself that’s at issue. But wp-geshi-highlight.css is never displayed in theme editor’s file list.

  • Brad
    December 15, 2011 at 05:41 · Reply

    JP, simple yet effective plugin. Thanks. I just wanted to find out if anyone is having the problem with losing the pre arguments once switching view from HTML to VISUAL in the post. What I am saying is for example, i have

     in the HTML view, once i switch to VISUAL and then back to HTML view, the syntax would go back to 
    .  This is a problem when i have > and < all over the place.  Any idea?
thanks.
  • Markus Ewald
    February 21, 2012 at 15:07 · Reply

    This plugin looks really good and from what I see in these comments, your support is just fantastic :)

    I tried it on my blog and while it does work fine overall, it seems to escape HTML entities a second time (for example; &lt; becomes &amp;lt;). Personally, I like to put code with HTML entities into my <pre />-tags so the post stays valid HTML even without a syntax highlighter installed (otherwise, everything inside the <pre />-tags would be fair game and you couldn’t post an actual </ pre> without accidentally ending the code snippet /and/ producing invalid HTML).

  • Markus Ewald
    February 21, 2012 at 17:32 · Reply

    Ah, I didn’t see the escaped="true" option. That does exactly what I want!

  • Bharat Mandava
    April 30, 2012 at 08:48 · Reply

    Fantastic plugin, its loading fast and displays code without any clutters.

  • Kolorowanie składni » Paweł Mazur
    May 12, 2012 at 17:32 · Reply

    [...] gotowych dodatków takich jak Better WordPress Syntax, czy WP-GeSHi-Highlight postanowiłem zrezygnować z tych udogodnień i wykorzystać naprawdę ciekawe i na dłużą metę [...]

  • chitgoks
    May 18, 2012 at 08:49 · Reply

    do you have plans to add a collapse feature for the code?

Leave a Reply

  

  

  

CAPTCHA Image

*

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">