Extension talk:SyntaxHighlight

Jump to: navigation, search

About this board


Previous discussion was archived at Extension talk:SyntaxHighlight/Archive 2017 on 2017-03-29.

Mayazcherquoi (talkcontribs)

How can I force Pygmentize to render output using the "colorful" style, as per: http://pygments.org/docs/styles/ ?

I have tried setting the following:

$wgPygmentizePath = '/usr/bin/pygmentize -S colorful';

However, this will just cause Pygmentize to error out on any pages containing a SyntaxHighlight block.


2001:8B0:CA07:C57A:127B:44FF:FE93:FAC4 (talkcontribs)

I too would be interested in how to do this. The <tt>-S</tt> option is not the correct one. I think you would need to edit the source of the extension to add

options['style'] = 'colorful';

However, I think you would also need to edit the <tt>maintenance/updateCSS.php</tt> script to also use that style, and run it, in order to update the CSS files in the <tt>modules/</tt> directory, as these are what define what the output actually looks like.

I tried all of that and although my colour scheme did change, it didn't come out looking correct. I wanted a dark style like a white-on-black terminal, but it persists in giving me a light grey background. Some further clues are missing.

For now I have switched to using the Highlightjs_Integration extension.

Reply to "Control Pygmentize style?"
Aschroet (talkcontribs)

On our 1.29.1-Installation we activated this plugin. The highliting works properly. Also the integration into the VE is generally working, i. e. when adding a code block it asks about language and line numbers. However, when "inserting" i only see the ugly wikitext but not a preview how it will look like after saving. Don't know if this is a bug or a missing feature. Any help appriciated.

Jdforrester (WMF) (talkcontribs)

I think this is T164120, an issue that was fixed about a year ago, and was released in the 1.30 branch of the code. If I'm right, when you upgrade this should be resolved for you. If I'm not and it's a different issue, please give some more details so we can track that.

Aschroet (talkcontribs)

I think it is another issue since i select a valid language and as a result i am getting a string shown in VE like <syntaxhighlight lang="java"> test </syntaxhighlight>. This string is marked in blue and there is a bubble "code block" with the edit button. Unfortunately, i cannot upgrade to 1.30 in my environment. Could you help to debug this issue. I already checked the parsoid log without any result.

Reply to "Preview within VE does not work"
Zewas (talkcontribs)

I'm using MediaWiki 1.28.2 and SyntaxHighlight 2.0. My system is a 64 bit Windows 10 machine.

The code ends up in a plain PRE tag and the page is added to category "Pages with syntax highlighting errors". Setting $wgShowExceptionDetails did not trigger any output. On a hunch I renamed pygmentize to pygmentize.exe, tried to run it via the command line and got this error message:

Unsupported 16-Bit Application

The program or feature "\\...\pygmentize.exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.

Is that the problem? Do I need a different version of pygmentize? Where do I get that?

Lanthanis (talkcontribs)

So you installed a x64 version of Python ?

Maybe you should try a x32 version Python and install Pygments again.

Zewas (talkcontribs)

In case anyone's interested, here's the solution:

  1. Find the file called pygmentize in the extensions\SyntaxHighlight_GeSHi folder.
  2. Move that file to your Apache's cgi-bin. If your server is set up reasonably well only executables in that magic directory will get executed.
  3. Install Python 2.7 because pygmentize is not really an executable. It's Python byte code and requires the python.exe to run.
  4. Make sure that the Python install directory is added to your system's PATH.
  5. Rename pygmentize to pygmentize.pyc. This is Windows. Extensions are magic here. No extension, no magic.
  6. Find the cgi-bin's AddHandler directive in your httpd.conf and add .pyc to the list if it isn't there already.
  7. Edit your LocalSettings.php and add this line somewhere:
    $wgPygmentizePath = '...\\cgi-bin\\pygmentize.pyc';
  8. Restart your server.

That worked for me. (talkcontribs)

Thank you very much! Your info helps me a lot. With the difference: I use IIS as Webserver.

MediaWiki Version 1.29

  1. You need to install Python 2.73 in default directory
  2. Map cgi extensions like here: http://haishibai.blogspot.de/2011/02/setting-up-python-on-iis-7_01.html(The Extension is "pyc" and not like in the link "py"!)
  3. Find the file called pygmentize in the extensions\SyntaxHighlight_GeSHi folder.Rename pygmentize to pygmentize.pyc. This is Windows. Extensions are magic here. No extension, no magic.
  4. Add this to LocalSettings.php

$wgPygmentizePath = 'C:\inetpub\wwwroot\Wiki\extensions\SyntaxHighlight_GeSHi\pygments\pygmentize.pyc';

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'HighlightJS' );

$wgHighlightJsMagic = 'syntaxhighlight';

$wgHighlightJsStyle = 'tomorrow-night-bright'; (talkcontribs)

I've tried this and it's still not working.

Server 2012 R2

IIS 8.5

python 2.73 installed in c:\Python27

Followed instructions above...scratching head. Is there a way to output the error....why it's not highlighting?

Rory.fewell (talkcontribs)

None of this worked for me either, I have gone through the PHP itself and there is little to no information I could find that helped solve the problem.

Instead I have opted to replace the faulty section of code with some basic PHP script that seems to work (at least for my machine).

Try this fix:

Open SyntaxHighlight.class.php in the mediawiki\extensions\SyntaxHighlight_GeSHi folder

Scroll to around line 211 to find the highlight function

Towards the end of this function, you should see an if statement like:

if ( $output === false) {

// does stuff here


Simply replace this entire if block with the following script, and it should fix the problem for you (edit the Python executable path as needed for your installation of course):

if ( $output === false ) {

           $optionPairs = [];

           foreach ( $options as $k => $v ) {

               $optionPairs[] = "{$k}={$v}";


           $execCmd = 'C:\\Python27\\python.exe ' . self::getPygmentizePath() . ' -f html -l ' . $lexer . ' -O ' . implode( ',', $optionPairs );           

           $descriptorSpec = array(

               0 => array('pipe', 'r'),

               1 => array('pipe', 'w')


           $proc = proc_open($execCmd, $descriptorSpec, $pipes);           

           fwrite($pipes[0], $code);


           $output = stream_get_contents($pipes[1]);



           $cache->set( $cacheKey, $output );



This should hopefully be a fix, if the results don't appear straight away it might be due to caching, in which case you can add $output = false; just before the if statement to reset it.

Hope it works for anyone else that's having problems, tested this on IIS 10

Reply to "Syntax highlighting does not work"

Call to undefined method MediaWiki\Shell\Command::input()

1 (talkcontribs)
Product Version
MediaWiki 1.31.0-alpha
HHVM 3.21.3 (srv)
MariaDB 10.0.32-MariaDB-0+deb8u1
ICU 52.1
SyntaxHighlight 2.0 (330ac62)12:31, 25 February 2018 GPL-2.0-or-later Provides syntax highlighting <syntaxhighlight> using Pygments - Python syntax highlighter Brion Vibber, Tim Starling, Rob Church, Niklas Laxström, Ori Livneh and Ed Sanders

# /usr/share/nginx/html/wiki/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize -V

Pygments version 2.2.0, (c) 2006-2017 by Georg Brandl. -- PS! I also tried v2.0.2 and specifying the path in LocalSettings.

[error] 683#683: *648 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Call to undefined method MediaWiki\Shell\Command::input() in /usr/share/nginx/html/wiki/extensions/SyntaxHighlight_GeSHi/includes/SyntaxHighlight.php on line 320" while reading response header from upstream, client:, server: mycoolhost.net, request: "POST /wiki/api.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "mycoolhost.net"   

                $output = $cache->getWithSetCallback(

                        $cache->makeGlobalKey( 'highlight', self::makeCacheKeyHash( $code, $lexer, $options ) ),


                        function ( $oldValue, &$ttl ) use ( $code, $lexer, $options, &$error ) {

                                $optionPairs = [];

                                foreach ( $options as $k => $v ) {

                                        $optionPairs[] = "{$k}={$v}";


                                $result = Shell::command(


                                        '-l', $lexer,

                                        '-f', 'html',

                                        '-O', implode( ',', $optionPairs )


                                        ->input( $code )

                                        ->restrict( Shell::RESTRICT_DEFAULT | Shell::NO_NETWORK )


                                if ( $result->getExitCode() != 0 ) {

                                        $ttl = WANObjectCache::TTL_UNCACHEABLE;

                                        $error = $result->getStderr();

                                        return null;


                                return $result->getStdout();



Any tips?

Reply to "Call to undefined method MediaWiki\Shell\Command::input()"
Tgds003 (talkcontribs)

i have a suggestion.

i want to reduce height of syntaxhighlight element when user doubleclick, so i added some code to Mediawiki:common.js.


$('.mw-highlight pre').dblclick(function(event) {

    if ($(event.target).parent().attr('class') == "scrolldiv") {


    } else {

        $(event.target).wrap('<div class="scrolldiv"/>');

        $('.scrolldiv').css({ height: '300px', overflow: 'auto' });




i thought it would be useful for someone.:)

thank you!

Dinoguy1000 (talkcontribs)

Instead of height, I'd suggest using max-height on .scrolldiv, so that the box won't be unnecessarily tall if there's only a handful of lines of code.

Tgds003 (talkcontribs)

yes, you are right.

but, max-height doesn't seem to work.

i think we should use the 'if' statement rather than max-height.

i edited a code, as follows


$('.mw-highlight pre').dblclick(function(event) {

if (parseInt($(this).css('height'), 10)>300){

if ($(this).parent().attr('class') == "scrolldiv") {


} else {

    $(this).wrap('<div class="scrolldiv"/>');

    $('.scrolldiv').css({ height: '300px', overflow: 'auto' });




Reply to "collapsible syntaxhighlight"
Aka sektor (talkcontribs)

Not work <syntaxhighlight lang="lua">

Aka sektor (talkcontribs)

Any news? (talkcontribs)

keep format as <nowiki><pre>..</pre></nowiki> but not colourize

on 1.29.1 either

Reply to "MW 1.29.0 bugs"
Brian denton (talkcontribs)

Syntaxhighlight works great for me, except I would like to use wiki markup/wikicode as the language. Is this implemented? I cannot find the lang argument (lang="wikicode" etc) anywhere.

IKhitron (talkcontribs)

It does not exists, unfortunately. You can try html, it can be helpful a little.

Brian denton (talkcontribs)

okay, thank you. PHP has a nice green tinge that looks kinda nice!

Martin Kraft (talkcontribs)

Since there is an wikitext-syntax-highlighting deployed in the new source-code-editor: Wouldn't it be possible to implement the very same functionality into this extension?

Considering, that Wikitext is them most commonly used language inside Wikis, it is really a pity, that we do not have any specific highlighting for help and example pPages.

Reply to "Wikicode as Lang"

Need a way to set a default language for default formatting

Noloader (talkcontribs)

We just installed/configured `SyntaxHighlight_GeSHi` after years of providing sample code without highlighting. We are a C++ library so nearly all of our sample code is C++.

We would like to set the default language to C++ and have GeSHi highlight all `<pre>` code to C++. Over time we will fix the highlighting issues.

Please provide a way to set a default language and have GeSHi highlight for it.

Reply to "Need a way to set a default language for default formatting"

Highlighting the syntax of the result of a template

Loizbec (talkcontribs)


I have a cargo db in my wiki, and I would like to display its content with a JSON syntax. So I created a template that does that. Now I would like to syntax highlight its content. I can't seem to do that, neither by adding the opening tag in the output of the template, nor, of course, by putting the call to the template between syntaxhighlight tags. (I even tried replacing the beginning and the end of my result with the tags after processing the whole content)

Anyone with a solution to that problem ?

Thanks in advance

--Loizbec (talk) 11:09, 16 November 2017 (UTC)

PerfektesChaos (talkcontribs)

If I understand correctly what you want to do, try this:


First, template cargo will be expanded, then result hilited.

Loizbec (talkcontribs)

Great !!! It works. Thanks a lot !

Reply to "Highlighting the syntax of the result of a template"
Seppl2013 (talkcontribs)

With the old "extension" for syntax highlighting GeSHi http://qbnz.com/highlighter/ i had created my own language highlighting files for some languages. I would now like to migrate those to pygmentize and add even more languages.


explains the principle and http://pygments.org/docs/lexerdevelopment/#adding-and-testing-a-new-lexer how to add and test lexers.

How do I add such a lexer to be "picked up" in the mediawiki environment?

What would be an "update safe" way to do this and if there is none yet where can I post a feature request for this?

Seppl2013 (talk) 08:57, 26 September 2017 (UTC)

PerfektesChaos (talkcontribs)

I am afraid you are to wait a while.

As far as I understand the procedure the entire pygments definitions are updating MediaWiki on a regular base.

That might happen once a year, after a couple of months, some years later. If an important language has been added to pygments, or a serious bug in a frequently used language pattern has been fixed, someone might feel urged to import the current state.

It looks rather settled to me now, and you might show a great advantage in a major language not yet supported to trigger an update.

Reply to "Adding new Languages"