Extension talk:SyntaxHighlight

Jump to navigation Jump to search

About this board

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

Disruption in syntaxhighlight codes

Summary by Sokote zaman


Sokote zaman (talkcontribs)

I insert <syntaxhighlight> codes into the page through the visual editor.

But after saving the page, and editing it again with the visual editor, I see the <syntaxhighlight> code incorrectly !!!

please guide me

Thanks (talkcontribs)

Same here. If anyone has a solution to this, it would be appreciated (talkcontribs)

Worked this out.

The Uri API param in my Parsoid config.yaml was set to http : / / localhost/api.php, but needed to point at the exact URL to avoid any 302 redirects.

Once changed to https: / / mywikihostname/api.php, SyntaxHighlighter started working correctly in Visual Editor :D

Sokote zaman (talkcontribs)

Thank you for your comment

Thank you very much!

My going was resolved and everything returned to normal


Dpleibovitz (talkcontribs)

The advanced section suggest using tags unmodified. If I use both noinclude and onlyinclude tags (within SyntaxHighlight) without modification, then SyntaxHighlight itself works perfectly. However, if I transclude that page, the onlyinclude tags are processed, because I assume, the transclusion engine doesn't look at the SyntaxHighlight tagging. I tried all sorts of work arounds ending with using an Xonlyinclude tag instead! PS. I can't surround the entire SyntaxHighlight section with noinclude tags because they also get mixed up with the ones inside the SyntaxHighlight section. Arg!

Is there a way of putting in something that looks like onlyinclude (and noinclude), that copy-and-pastes as if that was what they were, but is not looked at by the transclusion engine? Is this a bug with the transclusion engine? One solution with little extra CPU overhead is to allow nesting of noinclude tags, so in my case, if I surrounded the entire section outside SyntaxHighlight with noincludes, everything would come out fine. I would have a balanced nesting level of 2 and only when the 2nd ending is processed would transclussion continue... MediaWiki already supports nestings, but only across different tags and only with each having a depth of 1.

PS. I use MediaWiki 1.30.0. Perhaps this is already resolved...

PerfektesChaos (talkcontribs)

If you are using <syntaxhighlight> you will run into some syntax effects on internal affairs.

  • Reason: It is strongly desired that the presentation shows all printable characters (with some problems on whitespace variants) exactly as-is. Nothing shall be interpreted, whatever it might be, with exception of the closing </syntaxhighlight>.
  • The sequence of include tag processing and syntaxhighlight tag is not really defined; therefore you should not rely on any order and make your things robust.
  • Therefore your stuff might be represented as-is and is not subject to Wikitext parsing and processing.
  • Even more, nobody on upstream software would care about MediaWiki syntax problems.
  • Nobody will change any software to match your needs. That would break other things.
  • The behaviour on include tags goes for 15 years, and syntaxhighlight did not change anything, therefore MW version has no influence.

Solution: Use {{#tag:syntaxhighlight|some code to be parsed|lang=yourLang}} instead.

  • some code to be parsed will be parsed first, and they should obey include tags, if I recall correctly.
  • Be careful with unescaped pipe symbols.
  • After parameter 1 has been parsed as usual, which might contain template transclusions as well, the resulting string will be passed to syntaxhighlight tag.
  • You can even break meaning of include tags by: <<noinclude/>onlyinclude> syntax prevention.
  • In the end you will get a predictable and stable output.

When you transclude a processed page, you get the result of the cached page. In order to change appearance you need to reparse the contents under external conditions.

  • That is done by exposing the original code again.
  • Actually I did not completely understand what you are complaining about, but I am quite sure the remedy will help.
Dpleibovitz (talkcontribs)

Thank-you. Haven't used parser tags before. Still need to add many nowiki and noinclude tags, but at least I can get it to work!

Reply to "Advanced and transclusion"

Failed to invoke Pygments on Windows

Glanthor Reviol (talkcontribs)


I've just migrated and upgraded our company's MediaWiki to a new server. Windows Server 2012 R2, Apache 2.4.33 64bit + PHP 7.1.19 64bit + Python 3.6 64bit, MediaWiki 1.31.0.

Everything works except the SyntaxHighlight extension. The error message:

Notice:  Failed to invoke Pygments: 'C:\Python36\Scripts\pygmentize.exe" "-l" "css" "-f" "html" "-O" "cssclass' is not recognized as an internal or external command, operable program or batch file.

[Called from SyntaxHighlight::highlight in C:\Apache24\htdocs\wiki\extensions\SyntaxHighlight_GeSHi\includes\SyntaxHighlight.php at line 336] in C:\Apache24\htdocs\wiki\includes\debug\MWDebug.php on line 309

The PATH is set correctly, and from a sample test php file I can call Pygments, and it works:


$output = shell_exec('C:\Python36\Scripts\pygmentize.exe -l php -f html -O cssclass C:\Apache24\htdocs\test2.php');

echo "$output2";


I have tried several options, like using the exe: $wgPygmentizePath = "C:\\Python36\\Scripts\\pygmentize.exe"; or the bytecode from the cgi directory:

$wgPygmentizePath = "C:\\Apache24\\cgi-bin\\pygmentize.pyc"; but nothing helped. Please advise how to debug further this problem.

Daimona Eaytoy (talkcontribs)

I'm having the same problem, there are some system config differences (for instance, I run MediaWiki 1.32 master on XAMPP with PHP 7.2.2), but having the same identical error. Having two versions of Python in two different directories, I tried both of them (2.7 and 3.3), changed wgPygmentizePath to all possible combinations, set full user rights on pygmentize, added everything to PATH, but I'm still getting the same error. And, as Glanthor Reviol, I can indeed execute it from wiki folder using windows' cmd and also directly from SyntaxHighlight using exec. I really can't think of something more to do, sounds like there's some specific problem with Windows. BTW, SyntaxHighlight used to work correctly with an old version (can't recall which one) of the extension itself and MediaWiki, using Python 2.7.

Bar-ucholstebro (talkcontribs)

I seem to have the same problem on a MediaWiki 1.31.0, with both Python27 and Python37.

I read somwhere that there were som changes in Shell::command from MediaWiki 1.31.0 - and I traced the problem down to somwhere in that area, but could not find a fix for it.

Hope someone can find a fix for this problem.

Daimona Eaytoy (talkcontribs)

I wrote a short and shallow explanation on phabricator, see https://phabricator.wikimedia.org/T199989. Basically, I fear that this might be a very upstream problem, i.e. a PHP bug which won't be fixed (a couple of links on the task) since Windows doesn't actually provide the needed logic. More specifically, the problem as far as I understood it should be that on Windows you cannot set streams as not blocking, which then produces a conflict within shell pipes, entering in a vicious circle. If this is true, there's probably no easy or clean solution to this problem: we could only solve it with a workaround or by refactoring the shell code. But I guess we should really find a solution, since this problem affects a core feature (Shell) on a whole OS.

Fanoudu62219 (talkcontribs)

Hello everyone.

I have the same problem on my side. SyntaxHighlight isn't working since 1.32 update.

I understand the problem with PHP, sream problem etc but I'm looking for a solution, a workaround and since 2 months, I'm unable to find such solution.

Does somebody have a miracle for me ?


Daimona Eaytoy (talkcontribs)

Personally, I can't find one. Actually, I'm not completely sure about the cause, too. Any update will come on Phabricator, anyway.

Fanoudu62219 (talkcontribs)

Thanks for reply.

I am afraid that there is no updates on phabricator too ^^

Wait & see... (talkcontribs)

Any news? I have the same problem (talkcontribs)

I want to add that I have this problem as well, on the latest 1.33, latest Syntax_Highlighter from the repo, etc. I've fought with it for hours. Has anyone successfully used pygment on Windows? It seems like it'd almost be easier, at this point, just to go back to a version that worked, and figure out how to get 'json' support, which is what spawned this whole upgrade for me. (talkcontribs)

To add to my last comment, after upgrading to mediawiki-1.33.0, PHP 7.1.1, on Windows 7, and trying every bloody combination suggested in this thread (including editing the Syn*.php file, adding handler to httpd.conf and just on and on), there is absolutely no combination that 'works'. The closest is specifying the exe in a path AND editing the 'fixed' Rory solution below, but that only half works. Some items are colorized, but others are flat out hidden, with no error (if there's a highlight or lines tag). This is pathetic. I've wasted almost a whole day messing with this, and it just frustrates me I can't even downgrade now. (Older versions, pre-pygmentize, show no color at all?!!!).

The HightlightJs and Highlight-Integrate extensions don't seem to support highlighting code lines, or displaying line numbers.

Is this really that hard? Can anyone come up with an actual, fully working install for this bloody thing using MW1.33.0+ with xammp?

Sincerelywy (talkcontribs)

The problem has not been solved yet......I'm try to use syntaxhighlight, but no matter how the test is unsuccessful. Finally I found this article and I won't try anymore until the problem is solved.

OS: Windows 10 Professional Edition

XAMPP: Version 7.3.11 with Apache 2.4.41 and PHP 7.3.11 (VC15 X86 64bit thread safe) + PEAR

MySQL: Version 5.7.21

MediaWiki: Version 1.33.1 (talkcontribs)

Same issue here (Windows Server, IIS8.5, PHP7.4, Python 3.8.2, mw 1.34 - see Topic:Vibz8ak3wnpu9mv8 for more details

Reply to "Failed to invoke Pygments on Windows"

Discussion on the future of <source>

Dinoguy1000 (talkcontribs)

There is an ongoing discussion about the future of <source> on Phabricator. Current participants (including myself, for full disclosure) are leaning towards formal deprecation and eventual removal, and more input would be appreciated.

Reply to "Discussion on the future of <source>"

Dirty Hack to get it work on Windows

4 (talkcontribs)

Since passing parameters and results to the pygmentizer through stdin/stdout does not work on Windows,

i tried to use files for input and output. Pleas adjust the temporary directory to your environment.

Works for me on MediaWiki 1.33.


Ralf Naujokat

function ( $oldValue, &$ttl ) use ( $code, $lexer, $options, &$error ) {
	$optionPairs = [];
	foreach ( $options as $k => $v ) {
		$optionPairs[] = "{$k}={$v}";
	$tmp = tempnam( 'D:\\MediaWiki\\tmp', 'SH' );
	$tmp_out = $tmp . ".out";
	$tmp_in  = $tmp . ".in";
	file_put_contents( $tmp_in, $code );
	$result = Shell::command(
		self::getPygmentizePath() .
		' -l ' . $lexer .
		' -f ' . 'html' .
		' -O ' . implode( ',', $optionPairs ) . 
		' -o ' . $tmp_out . 
		' '    . $tmp_in 
		// ->input( $code )
		->restrict( Shell::RESTRICT_DEFAULT | Shell::NO_NETWORK )

	if ( $result->getExitCode() != 0 ) {
		$ttl = WANObjectCache::TTL_UNCACHEABLE;
		$error = $result->getStderr();
		return null;

	$out = file_get_contents( $tmp_out );
	unlink( $tmp );
	unlink( $tmp_in );
	unlink( $tmp_out );
	return $out;
} (talkcontribs)

Oops, forgot to mention:

Modify the file 'includes\SyntaxHighlight.php', starting at line 305 (talkcontribs)

Thank you so much for sharing this - I was ripping my hair out! (talkcontribs)

Also thank you, but have you get syntax highlighter working when attribute highlight is used (highlight="1,5,6" for example)?

Reply to "Dirty Hack to get it work on Windows"

how to change <source> into <syntaxhighlight>?

2 (talkcontribs)

Hi there,

I am using Geshi quite long and therefor all my pages use the code


do I need to change them all into "syntaxhiglight"?

PerfektesChaos (talkcontribs)

I would recommend that to avoid confusion with the HTML element, but there is no urgent need.

Reply to "how to change <source> into <syntaxhighlight>?"

Using composer to install after run Mediawiki Wizard

Krauss (talkcontribs)

There are a reported bug in the Mediawiki Wizard, so, it is a workaround.

  1. Solicitate SyntaxHighlight with the Online Mediawiki Wizard, and install it (the "bug install");
  2. Test to edit source code using the Wiki (edit some source tag)
  3. If not running:
    1. With SSH, at the Mediawiki folder, run again the Composer by the command php composer.phar update --no-dev.
    2. Check that is executable, ls -l /path/to/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize (will return for example -rwxr-xr-x).
      It this the most important after all install... Do chmod a+x path when necessary.
    3. Try again
    4. .... other checks

That the item 3.1, if try again, the messages will be:

> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies
Generating optimized autoload files
> ComposerVendorHtaccessCreator::onEvent

If there are some permission errors or a kind of "Composer: file_put_contents(./composer.json): failed to open stream", etc. Try:

  • sudo chown -R $USER yourHtmlMediawikiFolder/
  • sudo chown -R $USER ~/.composer/

and, after it, run composer again (item 3.1). You your user is a problem, after run composer put back www-data:

sudo chown -R www-data yourHtmlMediawikiFolder/.
Reply to "Using composer to install after run Mediawiki Wizard"

Highlighting and numbering skipping lines?

DukeEgr93 (talkcontribs)

I just updated to 1.32 and now the code that has highlights skips a line for the highlighting? Example at http://pundit.pratt.duke.edu/wiki/Sandbox Thoughts? The issue does not happen if line numbers are not requested. I'm running on Bluehost and...I will note the code that looks wrong on my site looks fine on this one so...merde.

DukeEgr93 (talkcontribs)

Edit: I had a $wgPygmentizePath in LocalSettings that pointed to the pygmentize because originally, after updating to 1.32, I didn't get colors. I just installed the newest version of pygmentize into the SyntaxHighlighter folder and got rid of the $wgPygmentizePath line and - poof - everything's good again!

Reply to "Highlighting and numbering skipping lines?"

Syntax highlighting 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.

Paintdog (talkcontribs)

This didn't worked for me (XAMPP-solution), Windows 10, Python 3.7 and Python 2.7. Thank you for sharing your solution, but it didn't worked... (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

Egon.allison (talkcontribs)

I battled with this myself. No matter what i tried it didnt work. Until i discovered this : Extension:Highlightjs Integration. This worked so well for me and i didnt need // wfloadextension( 'syntaxhighlight_geshi' ); in my LocalSettings.php. All i needed to add after following standard instructions (download, paste in folder etc...) was this line : wfloadextension( 'Highlightjs_Integration' ); in my LocalSettings.php

RockSheep (talkcontribs)

Is there a way to make it work in VisualEditor? For me the lines with code are displayed as blank lines.

Egon.allison (talkcontribs)

Hi RockSheep. I dont know the answer to this since I haven't yet played with VisualEditor before. I am sure that there must be a way to get it working since Highlightjs should work in any browser really...

Egon.allison (talkcontribs)

Also as a sidenote if you want to change the style change it in extension.json in the Highlightjs_Integration folder in the "styles" section. Should look like this  :


Egon.allison (talkcontribs) (talkcontribs)

Rory's solution needs a slight tweak in 1.31, but it works mostly, line 307:

I set this in LocalSettings.php and also renamed the pygmentize to pygmentize.pyc and setup a Script Mapping Handler in IIS.

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

$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}";

                $execCmd = 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);

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


                return $res;

Harm.frielink (talkcontribs)

SyntaxHighlight uses Python Pygmentize

If you are running MediaWiki on a Shared Host without cpanel installed, forget about using SyntaxHighlight.

It won't work! And that is very very sad!

Why are there python packages needed to make an extension? Don't do that! It is helping the developer to make it easier, but makes the portability of the extension not better, even worse or not working at all. Again very very sad issue here

Scott216 (talkcontribs)

I'm on a shared host with SiteGround and use cpanel. SyntaxHighlight isn't working for me any more. I guess I'll try another code highlighting extension.

WikimeSteve (talkcontribs)

Is there any news on this failure? We have a rather busy but recently built server. Along with the lack of colorization we also have each of the 98 pages where the tag is called showing up on Category:Pages with syntax highlighting errors. MediaWiki 1.31.0 PHP 7.2.9 (cgi-fcgi) MySQL 5.7.23-log

Will we be better off looking into a different solution like https://www.mediawiki.org/wiki/Extension:SyntaxHighlighterAndCodeColorizer which also shows as stable but a bit older?

Reply to "Syntax highlighting does not work"
Besuglov.S (talkcontribs)

If you upload whole mediawiki installation or just this extension via FTP manager that can use ASCII mode (for Filezilla use Edit -> Settings -> Transfers -> FTP:File Types and check OFF "Treat files without extension as ASCII files") for file transfer this extension wont work with error "zipimport.ZipImportError: bad local file header:".

Dinoguy1000 (talkcontribs)

If you're using an FTP manager to upload files to your server, and you mess with the ASCII mode settings, you're generally going to have a lot of problems of this nature; it's nothing specific to this extension (the default settings are default for a reason).

Besuglov.S (talkcontribs)

The thing is Filezilla defaults to "Treat files without extension as ASCII files" and pygmentize is falling into this category.

Filezilla uploads extension damaged.

I was unable to find zipimport error message anywhere on this page and it gives no clue about the actual problem.

Reply to "Installation / upload caveat"