WordPress.org

Ready to get started?Download WordPress

Plugin Directory

!This plugin hasn't been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

Highlight Source Pro

Powerful, XHTML-compliant, server-side code highlighting for pretty much all languages

I use Self-Formatted Markup in older posts, what's gonna happen?

As long as they aren't wrapped in <pre>-tags with a lang=-attribute nothing is going to happen - your markup will stay untouched. Highlight Source Pro only hooks in for those <pre>-tags having a lang=-attribute.

What about that class-abuse for line numbering???

The line-numbering is the one problem here, because - currently - it requires to break with the XHTML-Standard. Because the <ol> is always and guaranteed inside a <div> with the .geshi-class there is no need for the class-attribute on the list element. Also due to the fact that a CSS-classname is not allowed to start with a number, this solution is valid XHTML for downgrading and can never interfere with existing CSS-rules.

I can use all HTML for the title-line?

Yep. The basic idea is, once again, backwards compatibility. If you consider your code-blocks being important you'll most likely want to add a heading instead of just a line, on the other hand you can simply use the title-feature to show which file is being talked about. Since the title-string will be placed inside a <div> you'll be fine as long as there's no line-break (and your markup is valid)

What about that html_entity_decode thing and the enc__ - prefix??

There's two ways of handling code-listing in your original post source. You can either use the HTML-input and hardcode PHP, C or whatever you think about, statements in there, Highlight Source Pro will handle those listings without any problems (in fact, it's the safer version to use for Highlighting as all characters are present in their original form).

On the other hand this will get problematic if - for any reason - you stop using Highlight Source Pro, because WordPress (and every other serious software) will strip lots of those listings for security and compatibility reasons. If you want to be sure that your listings don't break when moving to another platform you should consider using htmlentities() on your listings, or writing them with the Visual Editor in the first place, so when falling back everything will be displayed as you want.

In this case you'll have to use the enc__-prefix to tell Highlight Source Pro to apply html_entity_decode() before the actual syntax-highlighting. While this might be the more default case it's still the one requiring the alteration with the prefix, for compatibility reasons. If encoded scripts would be marked with the original language-signature and the source would later on be used in another GeSHi-environment things would get very, very complicated and confusing.

Requires: 2.3 or higher
Compatible up to: 2.5
Last Updated: 2008-4-10
Downloads: 9,258

Ratings

4 stars
4 out of 5 stars

Support

Got something to say? Need help?

Compatibility

+
=
Not enough data

0 people say it works.
0 people say it's broken.

100,1,1
0,2,0
100,1,1
100,1,1