Extension talk:SyntaxHighlight GeSHi/Archive 2015
 | In MediaWiki 1.26 this extension went through a major rewrite and switched from the 3rd party library Geshi to the 3rd party library Pygments. Make sure to mention which version of MediaWiki you are using when asking questions. |
| Please do not make requests for support for languages or bug reports for highlighting errors on this page. This extension uses the Pygments library, which is not maintained by the MediaWiki developers. Bug reports and feature requests for the highlighting should be made to the Pygments developers. |
 | |
Archives
|
|---|
|
|
2015[edit]
With lang="sql" getting uppercase string SQL after a dot[edit]
Code:
<syntaxhighlight lang="sql"> @rdbms/admin/dbmsstat.sql @rdbms/admin/prvtstat.plb @rdbms/admin/utlrp.sql </syntaxhighlight>
Results in
@rdbms/admin/dbmsstat.SQL @rdbms/admin/prvtstat.plb @rdbms/admin/utlrp.SQL
It seems only to be happening with the sql-extension. I know that when running the above commands you can leave out the sql-extension, but it happens also when I want to spool output to another sql-file, and then I can't omit the extension.
The workaround is to put it between double quote, e.g
@"rdbms/admin/dbmsstat.sql"
but that doesn't look too nice in my wiki-page.
Thought to solve it by editing sql.php in extensions/SyntaxHighlight_GeShi/geshi/geshi and remove SQL from the keywords-array but that didn't solve it.
I run a site with Mediawiki 1.23.10. And it also happens when using source lang="sql" instead of syntaxhighlight.
Is this a bug or an (undocumented) feature? Or am I overlooking something completely?
Code with <dl>s cause bad things[edit]
There's a bug that I'm running into:
;Here's a dt :Here's a dd that contains code with line numbers :<syntaxhighlight lang="lua" line="GESHI_FANCY_LINE_NUMBERS"> print "Everything is ok" print "Everything is still ok" </syntaxhighlight> : And here's one that doesn't have numbers :<syntaxhighlight lang="lua"> print "Everything is ok" print "Everything is no longer ok" </syntaxhighlight> :That did not work so well...
Gives:
- Here's a dt
- Here's a dd that contains code with line numbers
print "Everything is ok" print "Everything is still ok"
- And here's one that doesn't have numbers
print "Everything is ok" print "Everything is no longer ok"
- That did not work so well...
Eric Wieser (talk) 19:28, 22 May 2015 (UTC)
Loading method[edit]
Hello, It is said in the extension's wikipage that SyntaxHighlight_GeSHi should be load with :
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
In my case (mw 1.24), it breaks the server (it gives blank page for every requests)
This worked fine :
require_once "$IP/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php";
Can be a good idea to adapt the page to avoid other mistakes.
Thanks for your work !
Jona (talk) 07:41, 22 June 2015 (UTC)
- Thanks for mentioning this. This was documented on the extension's page by now. --[[kgh]] (talk) 12:53, 22 July 2015 (UTC)
Wrong C++ highlighting (solved)[edit]
- This is a bug report for the C++ lexer, where can I post it? The GeSHi project in the link on the top of this site does not longer exist … --Prog (talk) 20:18, 26 June 2015 (UTC)
- I have reported it at pygments, the new base of the SyntaxHighlight extension. --Prog (talk) 15:07, 28 June 2015 (UTC)
I have some wrong highlightings in the Version on de.wikibooks (same as here):
// integer literals:
234; // decimal, OK
0234; // octal, OK
0x1234abCD; // hexadecimal, OK
0X1234abCD; // hexadecimal, fail
0b1010; // binary, fail
0B1010; // binary, fail
1; // OK
1u; // OK
1U; // OK
1l; // OK
1L; // OK
1ll; // OK
1LL; // OK
1ul; // OK
1Ul; // OK
1uL; // OK
1UL; // OK
1ull; // OK
1Ull; // OK
1uLL; // OK
1ULL; // OK
01; // OK
01u; // OK
01U; // OK
01l; // OK
01L; // OK
01ll; // OK
01LL; // OK
01ul; // OK
01Ul; // OK
01uL; // OK
01UL; // OK
01ull; // OK
01Ull; // OK
01uLL; // OK
01ULL; // OK
0x1; // OK
0x1u; // OK
0x1U; // OK
0x1l; // OK
0x1L; // OK
0x1ll; // OK
0x1LL; // OK
0x1ul; // OK
0x1Ul; // OK
0x1uL; // OK
0x1UL; // OK
0x1ull; // OK
0x1Ull; // OK
0x1uLL; // OK
0x1ULL; // OK
0b1; // fail
0b1u; // fail
0b1U; // fail
0b1l; // fail
0b1L; // fail
0b1ll; // fail
0b1LL; // fail
0b1ul; // fail
0b1Ul; // fail
0b1uL; // fail
0b1UL; // fail
0b1ull; // fail
0b1Ull; // fail
0b1uLL; // fail
0b1ULL; // fail
// integer literals with ' as separator always fail:
1'123'456'789; // same as 1234567890
0123'456; // same as 0123456
0xABCD'1234; // same as 0xABCD1234
0XABCD'1234; // same as 0XABCD1234
0b1111'0000'0000; // same as 0b111100000000
0B1111'0000'0000; // same as 0B111100000000
// the ' can appear as separator on every position of an integer but for direct
// after a prefix (0, 0b, 0B, 0x or 0X), after another ' ('' is not allowed)
// and of course at the begin and after the last _digit_ (not suffix) of an integer literal
978'3'446'43981'8; // is a correct integer literal, same as 9783446439818
// (it is an ISBN, as example for a not equidistant separation use case)
// floating point literals:
4.24; // OK
4.24f; // OK
4.24F; // OK
4.24l; // The 'l' must be part of the literal
4.24L; // The 'L' must be part of the literal
4.2e4; // OK
4.2e+4; // OK
4.2e-4; // OK
4.2e4f; // The 'f' must be part of the literal
4.2e+4f; // The 'f' must be part of the literal
4.2e-4f; // The 'f' must be part of the literal
4.2e4F; // The 'F' must be part of the literal
4.2e+4F; // The 'F' must be part of the literal
4.2e-4F; // The 'F' must be part of the literal
4.2e4l; // OK
4.2e+4l; // OK
4.2e-4l; // OK
4.2e4L; // OK
4.2e+4L; // OK
4.2e-4L; // OK
4.2E4; // OK
4.2E+4; // OK
4.2E-4; // OK
4.2E4f; // The 'f' must be part of the literal
4.2E+4f; // The 'f' must be part of the literal
4.2E-4f; // The 'f' must be part of the literal
4.2E4F; // The 'F' must be part of the literal
4.2E+4F; // The 'F' must be part of the literal
4.2E-4F; // The 'F' must be part of the literal
4.2E4l; // OK
4.2E+4l; // OK
4.2E-4l; // OK
4.2E4L; // OK
4.2E+4L; // OK
4.2E-4L; // OK
// character and c-string literals:
'a'; // OK
u'a'; // The 'u' must be part of the literal
U'a'; // The 'U' must be part of the literal
L'a'; // OK
"I am a Text"; // OK
u"I am a Text"; // The 'u' must be part of the literal
U"I am a Text"; // The 'U' must be part of the literal
L"I am a Text"; // OK
// also all raw string literals are not supported
// with C++17 the following literals will also become correct:
// --> begin C++17
u8'a';
u8"I am a Text";
// <-- end C++17
Here are the formal definitions of C++ literals:
- integer_literal
- floating_literal
- character_literal
- string_literal
- user_literal (not described above, but also not supported by GeSHi)
Kind regards! --Prog (talk) 18:57, 26 June 2015 (UTC)
line property destroys copy & paste code (solved)[edit]
When I use the line property, I can't select the source without the line numbers:
def quickSort(arr):
less = []
This is very disruptive! The line property is a very nice feature, but it destroys all my code examples when I use copy & paste, so I can not use it without much trouble for the readers. --Prog (talk) 20:16, 26 June 2015 (UTC)
- solved via CSS:
.mw-highlight .lineno { user-select:none; }on Mediawiki:common.css. --Prog (talk) 15:37, 28 June 2015 (UTC)
MediaWiki:Geshi.css[edit]
Since the GeSHi update, all the present code is non-functional, as none of the referenced classes are no longer used. However, what is the status of MediaWiki:Geshi.css? Is it still loaded? -- [[User:Edokter]] {{talk}} 14:42, 28 June 2015 (UTC)
- I guess this needs to be filed on Phabricator. Currently no developer seems to be involved in looking at this talk page. Cheers --[[kgh]] (talk) 12:51, 22 July 2015 (UTC)
- Doesn't seem even basic diligence was exercised in testing it or considering the needs of the vast number of end users, given the large number of breaking changes. I wonder why this couldn't be done as a new alternate extension for people who weren't happy with the GeSHi-based one instead of overwriting what was a stable product for years. --QuasarEE (talk) 16:22, 24 July 2015 (UTC)
inline[edit]
Please deprecate inline and suggest enclose="none" for proper XML. Some of us (=me+maybe others) still recall the hilarious disabled="disabled" in XHTML1, and not all backward steps in HTML5 are better than XHTML1 transitional. –Be..anyone (talk) 22:19, 16 July 2015 (UTC)
Can't use SyntaxHighlight inline with a list[edit]
In the past i was able to use the extension Extension:Code with a list like this,
* the code
*: <code lang="diff">
--- common.inc 2015-03-06 00:32:26.000000000 +0200
+++ /tmp/drupal-6.21/includes/common.inc 2011-05-25 23:02:48.000000000 +0300
@@ -1901,9 +1901,7 @@
// starting with "ad*".
$filename = 'css_'. md5(serialize($types) . $query_string) .'.css';
$preprocess_file = drupal_build_css_cache($types, $filename);
- // HACKED - Asaph - added title to the CSS link tag
- $output .= '<link type="text/css" title="default" rel="stylesheet" media="'. $media .'" href="'. base_path() . $preprocess_file .'" />'."\n";
- //$output .= '<link type="text/css" rel="stylesheet" media="'. $media .'" href="'. base_path() . $preprocess_file .'" />'."\n";
+ $output .= '<link type="text/css" rel="stylesheet" media="'. $media .'" href="'. base_path() . $preprocess_file .'" />'."\n";
}
}
</code>
And the code block was indent correctly.
But now when i use SyntaxHighlight the same way it brakes horribly (you can see it here http://imgur.com/a/wCjp8),
and i need to put the opening tag on a new line to make it work.
I'm running
- MW 1.25.1
- SyntaxHighlight 1.0.8.12
-- UPDATE I downloaded a new version of SyntaxHighlight (Version 2.0) from the git, extracted it, and installed with composer, and it seems to work like before.
REL1_24 currently broken[edit]
→ Filed as task T106383
To fix this line 39 of "SyntaxHighlight_GeSHi.php" has to be commented out. Cheers --[[kgh]] (talk) 12:49, 22 July 2015 (UTC)
SyntaxHighlight geshi isent working for me[edit]
Hi I am using mediawiki 1.26 wmf 17 and latest code from master branch from today my wiki at http://en.random-wikisaur.tk/wiki/MediaWiki:Common.css isent highlighting anything since using new code because of switch from geshi to another syntax highlighter how do I enable it to highlight it is using all the default settings for syntaxhighligh geshi. Paladox2017 (talk) 16:42, 6 August 2015 (UTC)
An omission in the installation instructions[edit]
The installation instructions say
Download and place the file(s) in a directory called SyntaxHighlight_GeSHi in your extensions/ folder.
Add the following code at the bottom of your LocalSettings.php:
Done - Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
Err, what code? Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 08:18, 10 August 2015 (UTC)
- Hi this has been fixed. This was misktake when the template was updated. Should work now Paladox2017 (talk) 13:09, 12 August 2015 (UTC)
- Okay, it's fine now. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 18:43, 13 August 2015 (UTC)
Pigments Missing?[edit]
I'm seeing the following error when trying to use the master build of Syntaxhighlighter with MW 1.26wmf16. I cloned the repo, ran composer install and even went in and ran 'python create_pygmentize_bundle' in SyntaxHighlight_GeSHi/pygments/pygmentize. Code blocks are showing up and unformatted
blocks and the ""Pages with syntax highlighting errors" category is being applied.
The most interesting chunk of the below error is this portion (to me at least).
[warning] Failed to invoke Pygments. Please check that Pygments is installed and that $wgPygmentizePath is accurate. [Called from SyntaxHighlight_GeSHi::highlight in /var/www/html/w/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 2
[error-json] {"id":"5b24bf3b","type":"ErrorException","file":"/var/www/html/w/extensions/SyntaxHighlight_GeSHi/vendor/symfony/process/Process.php","line":1102,"message":"PHP Deprecated: The Symfony\\Component\\Process\\Process::setStdin method is deprecated since version 2.5 and will be removed in 3.0. Use the setInput() method instead.","code":0,"url":"/wiki/Test_Entry","suppressed":true,"backtrace":[{"function":"handleError","class":"MWExceptionHandler","type":"::","args":["integer","string","string","integer","array"]},{"file":"/var/www/html/w/extensions/SyntaxHighlight_GeSHi/vendor/symfony/process/Process.php","line":1102,"function":"trigger_error","args":["string","integer"]},{"file":"/var/www/html/w/extensions/SyntaxHighlight_GeSHi/vendor/kzykhys/pygments/src/KzykHys/Pygments/Pygments.php","line":65,"function":"setStdin","class":"Symfony\\Component\\Process\\Process","type":"->","args":["string"]},{"file":"/var/www/html/w/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php","line":279,"function":"highlight","class":"KzykHys\\Pygments\\Pygments","type":"->","args":["string","string","string","array"]},{"file":"/var/www/html/w/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php","line":125,"function":"highlight","class":"SyntaxHighlight_GeSHi","type":"::","args":["string","string","array"]},{"function":"parserHook","class":"SyntaxHighlight_GeSHi","type":"::","args":["string","array","Parser","PPFrame_DOM"]},{"file":"/var/www/html/w/includes/parser/Parser.php","line":4228,"function":"call_user_func_array","args":["array","array"]},{"file":"/var/www/html/w/includes/parser/Preprocessor_DOM.php","line":1260,"function":"extensionSubstitution","class":"Parser","type":"->","args":["array","PPFrame_DOM"]},{"file":"/var/www/html/w/includes/parser/Parser.php","line":3336,"function":"expand","class":"PPFrame_DOM","type":"->","args":["PPNode_DOM","integer"]},{"file":"/var/www/html/w/includes/parser/Parser.php","line":1231,"function":"replaceVariables","class":"Parser","type":"->","args":["string"]},{"file":"/var/www/html/w/includes/parser/Parser.php","line":434,"function":"internalParse","class":"Parser","type":"->","args":["string"]},{"function":"parse","class":"Parser","type":"->","args":["string","Title","ParserOptions","boolean","boolean","integer"]},{"file":"/var/www/html/w/includes/StubObject.php","line":105,"function":"call_user_func_array","args":["array","array"]},{"file":"/var/www/html/w/includes/StubObject.php","line":129,"function":"_call","class":"StubObject","type":"->","args":["string","array"]},{"file":"/var/www/html/w/includes/content/WikitextContent.php","line":331,"function":"__call","class":"StubObject","type":"->","args":["string","array"]},{"file":"/var/www/html/w/includes/content/WikitextContent.php","line":331,"function":"parse","class":"StubObject","type":"->","args":["string","Title","ParserOptions","boolean","boolean","integer"]},{"file":"/var/www/html/w/includes/content/AbstractContent.php","line":497,"function":"fillParserOutput","class":"WikitextContent","type":"->","args":["Title","integer","ParserOptions","boolean","ParserOutput"]},{"file":"/var/www/html/w/includes/poolcounter/PoolWorkArticleView.php","line":140,"function":"getParserOutput","class":"AbstractContent","type":"->","args":["Title","integer","ParserOptions"]},{"file":"/var/www/html/w/includes/poolcounter/PoolCounterWork.php","line":123,"function":"doWork","class":"PoolWorkArticleView","type":"->","args":[]},{"file":"/var/www/html/w/includes/page/Article.php","line":676,"function":"execute","class":"PoolCounterWork","type":"->","args":[]},{"file":"/var/www/html/w/includes/actions/ViewAction.php","line":44,"function":"view","class":"Article","type":"->","args":[]},{"file":"/var/www/html/w/includes/MediaWiki.php","line":456,"function":"show","class":"ViewAction","type":"->","args":[]},{"file":"/var/www/html/w/includes/MediaWiki.php","line":255,"function":"performAction","class":"MediaWiki","type":"->","args":["Article","Title"]},{"file":"/var/www/html/w/includes/MediaWiki.php","line":677,"function":"performRequest","class":"MediaWiki","type":"->","args":[]},{"file":"/var/www/html/w/includes/MediaWiki.php","line":474,"function":"main","class":"MediaWiki","type":"->","args":[]},{"file":"/var/www/html/w/index.php","line":41,"function":"run","class":"MediaWiki","type":"->","args":[]}]}
[warning] Failed to invoke Pygments. Please check that Pygments is installed and that $wgPygmentizePath is accurate. [Called from SyntaxHighlight_GeSHi::highlight in /var/www/html/w/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 2
- Hmm, this talk page appears to be abandoned by developers. I presume that going Phabricator with this issue draws more attention. Cheers --[[kgh]] (talk) 17:26, 17 August 2015 (UTC)
- Good idea. phab:T110079 Ckoerner (talk) 17:56, 24 August 2015 (UTC)
lang="oz" ?[edit]
Hi, in the list of "Previously supported lexers", "oz" has no strike-through, but it doesn't seem to be supported by Pygments (see fr:Oz (langage)). --NicoV (talk) 12:23, 8 September 2015 (UTC)
ignore line attribute when attribute "line" set to "off"[edit]
motivation: I would like to create a template that (among other things) calls syntaxhighlight via parser function {{#tag}}.
unfortunately neither
{{#tag:syntaxhighlight|{{{code|{{{2}}}}}}|lang="{{{lang|{{{1|text}}}}}}"|start="{{{start|1}}}"|highlight="{{{highlight|}}}"|{{#if:{{{line|}}}|line=1}}
nor
{{#tag:syntaxhighlight|{{{code|{{{2}}}}}}|lang="{{{lang|{{{1|text}}}}}}"|start="{{{start|1}}}"|highlight="{{{highlight|}}}"{{#if:{{{line|}}}|{{!}}line=1}}
works. with both examples, you cannot activate line numbering.
My only solution so far is to patch the extension [0], then somthing like this works perfect:
{{#tag:syntaxhighlight|{{{code|{{{2}}}}}}|lang="{{{lang|{{{1|text}}}}}}"|start="{{{start|1}}}"|highlight="{{{highlight|}}}"|line="{{{line|on}}}"}}
So my request: Does anyone have a solution to the problem? Otherwise, would it be possible, to make a small change to the extension to allow for setting the "line" attribute but ignoring it nonetheless?
[0] my so called patch to SyntaxHighlight_GeSHi.class.php
// Line numbers
if( isset( $args['line'] ) && $args['line'] != 'off' )
$geshi->enable_line_numbers( GESHI_FANCY_LINE_NUMBERS );
}
regards, Tobias
Tobias Oetterer (talk) 15:11, 2 October 2015 (UTC)
Does not work for languages with code containing dash[edit]
For example:
<syntaxhighlight line lang="cpp-qt">
#include <QtGui/QApplication>
#include <QTextCodec>
#include "mainwindow.h"
int main(int argc, char *argv[])</nowiki>
{
QApplication a(argc, argv);
}
</syntaxhighlight>
In mine MW it looks like this:
But if I choose any other language without dash in code (cpp for example), it works fine:
It happened after updating MW from 1.21 to 1.25.
I tried to update SyntaxHighlight GeSHi, but it didn't help.
Abagnale OS Ubuntu 14.04.2 LTS; MW 1.25.3; MySQL 5.5.43; PHP 5.5.9 19:50, 11 November 2015 (UTC)
Installed from git and I get a bad lang attribute[edit]
Bad lang attribute just like on the mediawiki page. I'm using languages like bash and javascript. Unsure of what I'm doing wrong??
- If you downloaded SyntaxHighlight GeSHi from Git, you will have to do a composer install (or was it composer update?) in the extension folder in order to get the dependencies. --88.130.109.128 01:44, 26 November 2015 (UTC)
- Thanks. I've cloned a fresh git repo and then composer update and it solved it:
cd extensions mv SyntaxHighlight_GeSHi SyntaxHighlight_GeSHi.bak git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/SyntaxHighlight_GeSHi.git cd SyntaxHighlight_GeSHi composer update
- --Ioannis Protonotarios 07:59, 30 December 2015 (UTC)
Hightlighting for templates and wiki[edit]
How to enable highlight in quoted code of templates (ParserFunctions), when quoting it in wikipedia? And also of wikicode (brackets {{}} [[]])? Example:
{{#if:{{{3}}}|{{{3}}}|{{{1}}}}}
- What you're asking for is wikitext support. I quote from Extension:SyntaxHighlight_GeSHi#Supported_languages:
- "Pygments does not yet provide a "wikitext" or "mediawiki" lexer. Use "html" instead. (see: phab:T29828)"
Invoke pygmentize on Windows machines[edit]
SyntaxHighlight_GeSHi will not work on Windows machines, because Windows doesn't know, that it has to use Python for the pygmentize package. So you have to rename pygmentize to pygmentize.py and to set the $wgPygmentizePath Variable in your LocalSettings.php.
$wgPygmentizePath = "$IP\\extensions\\SyntaxHighlight_GeSHi\\pygments\\pygmentize.py";
In my opinion it should not be to hard to solve this inconvenience in the next revision.
There's also a problem described in http://stackoverflow.com/questions/28398163/laravel-symfony-process-component-fails-to-start-new-process which I encountered on my Windows 7 x64 machine. Shortly, Symfony\Process doesn't start python (or any other) process correctly nor reads any results of the pygmentize package. My simple workaround was to get rid of the Symfony\Process component in the implementation of the highlight function in extensions\SyntaxHighlight_GeSHi\SyntaxHighlight_GeSHi.php file, and replace it by calls to PHP IO functions. The code is below (see the part which is commented out). Any better solution would be highly appreciated.
public static function highlight( $code, $lang = null, $args = array() ) {
global $wgPygmentizePath;
$status = new Status;
$lexer = self::getLexer( $lang );
if ( $lexer === null && $lang !== null ) {
$status->warning( 'syntaxhighlight-error-unknown-language', $lang );
}
$length = strlen( $code );
if ( strlen( $code ) > self::HIGHLIGHT_MAX_BYTES ) {
$status->warning( 'syntaxhighlight-error-exceeds-size-limit',
$length, self::HIGHLIGHT_MAX_BYTES );
$lexer = null;
}
if ( wfShellExecDisabled() !== false ) {
$status->warning( 'syntaxhighlight-error-pygments-invocation-failure' );
wfWarn(
'MediaWiki determined that it cannot invoke Pygments. ' .
'As a result, SyntaxHighlight_GeSHi will not perform any syntax highlighting. ' .
'See the debug log for details: ' .
'https://www.mediawiki.org/wiki/Manual:$wgDebugLogFile'
);
$lexer = null;
}
$inline = isset( $args['inline'] );
if ( $lexer === null ) {
if ( $inline ) {
$status->value = htmlspecialchars( trim( $code ), ENT_NOQUOTES );
} else {
$pre = Html::element( 'pre', array(), $code );
$status->value = Html::rawElement( 'div', array( 'class' => self::HIGHLIGHT_CSS_CLASS ), $pre );
}
return $status;
}
$options = array(
'cssclass' => self::HIGHLIGHT_CSS_CLASS,
'encoding' => 'utf-8',
);
// Line numbers
if ( isset( $args['line'] ) ) {
$options['linenos'] = 'inline';
}
if ( $lexer === 'php' && strpos( $code, '<?php' ) === false ) {
$options['startinline'] = 1;
}
// Highlight specific lines
if ( isset( $args['highlight'] ) ) {
$lines = self::parseHighlightLines( $args['highlight'] );
if ( count( $lines ) ) {
$options['hl_lines'] = implode( ' ', $lines );
}
}
// Starting line number
if ( isset( $args['start'] ) ) {
$options['linenostart'] = $args['start'];
}
if ( $inline ) {
$options['nowrap'] = 1;
}
$cache = ObjectCache::getMainWANInstance();
$cacheKey = self::makeCacheKey( $code, $lexer, $options );
$output = $cache->get( $cacheKey );
if ( $output === false ) {
$optionPairs = array();
foreach ( $options as $k => $v ) {
$optionPairs[] = "{$k}={$v}";
}
/*$builder = new ProcessBuilder();
$builder->setPrefix( $wgPygmentizePath );
$process = $builder
->add( '-l' )->add( $lexer )
->add( '-f' )->add( 'html' )
->add( '-O' )->add( implode( ',', $optionPairs ) )
->getProcess();
$process->setInput( $code );
$process->run();
if ( !$process->isSuccessful() ) {
$status->warning( 'syntaxhighlight-error-pygments-invocation-failure' );
wfWarn( 'Failed to invoke Pygments: ' . $process->getErrorOutput() );
$status->value = self::highlight( $code, null, $args )->getValue();
return $status;
}
$output = $process->getOutput();*/
$tempnm = tempnam(sys_get_temp_dir(), "pygm");
$temp = fopen($tempnm, "w");
fwrite($temp, $code);
$command = $wgPygmentizePath . " -l " . $lexer . " -f html -O " . implode( ',', $optionPairs ) . " " . $tempnm . " 2>&1";
$pid = popen( $command,"r");
while( !feof( $pid ) )
{
$output.= fread($pid, 256);
flush();
ob_flush();
usleep(1);
}
pclose($pid);
fclose($temp);
$cache->set( $cacheKey, $output );
}
if ( $inline ) {
$output = trim( $output );
}
$status->value = $output;
return $status;
}
Windows Issues[edit]
Actually it works just fine under Windows.
If you have an issue with
PHP Warning: fopen(): Filename cannot be empty in C:\inetpub\mediawiki\vendor\symfony\process\Pipes\WindowsPipes.php on line 55
and your sys_temp_dir in php.ini is set to e.g. C:\Windows\Temp\PHP (or C:\Windows\Temp or any folder under C:\Windows\Temp) you will probably run into this issue. Even if otherwise MediaWiki and PHP are working just fine (can write to $tmp folder).
In my case, IUSR (the user account which is the identity of the app pool in which my dev wiki web site is running) had write permissions on $tmp folder. The issue is, that this user also needs READ permissions on C:\Windows\Temp folder.
Also DO install Python 2.7.x and Pygmentize (pip install pygments), then set:
$wgPygmentizePath = "c:\\Python27\\Scripts\\pygmentize.exe";
Hope this helps someone. Blaz
- This helped me, immensely. Thank you! --Erutan409 (talk) 16:45, 20 January 2016 (UTC)