Difference between revisions of "GeSHi"
m |
(legacy) |
||
(29 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | [[ | + | {{legacy}} |
− | The standard GeSHi MediaWiki extensions don't quite suit our purposes because our articles containing code are usually directly executed which means that we can't include GeSHi code tags. | + | {{Note|The syntax highlighting extension used on OD is old, see [[MW:Extension:GeSHiCodeTag]], there is a newer syntax highlighting extension [[MW:Extension:SyntaxHighlight GeSHi]]. But as of mid 2015 we're using the [https://highlightjs.org HighlightJS] client-side syntax highlighter wrapped in [[Extension:HighlightJS]]. |
+ | }} | ||
+ | |||
+ | |||
+ | == Syntax highlighting on Organic Design == | ||
+ | The standard GeSHi MediaWiki extensions don't quite suit our purposes because our articles containing code are usually directly executed which means that we can't include GeSHi code tags, but this problem can be easily fixed by a quick hack which I've included here. | ||
+ | |||
+ | Another problem is that we'd often like the ability to use MediaWiki templates even if the content is code, for example when defining ''LocalSettings'' articles by transcluding the [[Template:Wiki|wiki template]] and extension templates. So I've also added an extra line of code into the GeSHi extension before it parses the content to achieve this: | ||
+ | |||
+ | == Using syntax highlighting on Organic Design wikis == | ||
+ | Blocks of source code can be wrapped in language tags like usual, as follows: | ||
+ | <source> | ||
<php> | <php> | ||
+ | print "foo"; | ||
+ | </php> | ||
+ | </source> | ||
+ | |||
+ | but also template syntax can be used to make the entire article be rendered by the GeSHi parser. The templates expand to nothing, so they can be placed anywhere in the article without affecting its execution (if the raw article is requested, ''templates=expand'' will need to be included in the query-string to make the template reduce to nothing). It's probably best to put the template in a comment so that the execution is not affected even if templates do not expand. Here's an example: | ||
+ | <source> | ||
+ | # {{per1}} | ||
+ | print "bar"; | ||
+ | </source> | ||
+ | |||
+ | == Technical == | ||
+ | To get around these issues, I've added a few extra lines after the GeSHi include to allow the tags to be added before parsing if a language template is transcluded. Here's the additional code which as added at the end of the GeSHiCodeTag.php file. | ||
+ | <source lang="php"> | ||
include('extensions/geshi/GeSHiCodeTag.php'); | include('extensions/geshi/GeSHiCodeTag.php'); | ||
$wgHooks['ParserBeforeStrip'][] = 'GeSHi'; | $wgHooks['ParserBeforeStrip'][] = 'GeSHi'; | ||
function GeSHi(&$parser, &$text, &$strip_state) { | function GeSHi(&$parser, &$text, &$strip_state) { | ||
− | + | if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'raw' || $_REQUEST['action'] == 'xml')) return true; | |
− | + | if (preg_match('/\\{\\{(xml|bash|php|perl|c|r|as|js|css|sql)\\}\\}/i',$text,$m)) $text = "<$m[1]>\n$text\n</$m[1]>"; | |
− | + | return true; | |
− | + | </source> | |
− | </php> | + | |
+ | Templates or variables must be added which expand to nothing so they don't render as a red link. Also an extra line must be added to the [[GeSHiCodeTag.php]] file just before the geshi object is instantiated in the hook function to force the templates to expand. | ||
+ | <source lang="php"> | ||
+ | $source = trim($GLOBALS["wgParser"]->replaceVariables($source)); | ||
+ | </source> | ||
+ | |||
+ | The end of the function needs to have a hack added to remove some spurious &lt;'s and &gt;'s that crop up on transcluded code: | ||
+ | <source lang="php"> | ||
+ | $text = $geshi->parse_code(); | ||
+ | $text = preg_replace("/&([lg]t;)/","&$1",$text); | ||
+ | return $text; | ||
+ | </source> | ||
+ | |||
+ | == Bugs == | ||
+ | The geshi syntax highlighter has a language called <nowiki><</nowiki>div>, this interferes with any wiki site <nowiki><</nowiki>div> tags. To suppress this bug either delete the language file, of rename it to <nowiki><</nowiki>div-lang>. | ||
− | + | == See also == | |
− | + | *[http://meta.wikimedia.org/wiki/GeSHiCodeTag_Extension GeSHiCodeTag Extension] ''- the GeSHi extension which worked most easily for us'' | |
− | + | *[http://svn.organicdesign.co.nz/filedetails.php?repname=extensions&path=%2Fgeshi%2FGeSHiCodeTag.php GeSHiCodeTag.php] ''- the code with adjustments added'' | |
− | + | [[Category:MediaWiki]] |
Latest revision as of 17:46, 22 May 2015
Contents
Syntax highlighting on Organic Design
The standard GeSHi MediaWiki extensions don't quite suit our purposes because our articles containing code are usually directly executed which means that we can't include GeSHi code tags, but this problem can be easily fixed by a quick hack which I've included here.
Another problem is that we'd often like the ability to use MediaWiki templates even if the content is code, for example when defining LocalSettings articles by transcluding the wiki template and extension templates. So I've also added an extra line of code into the GeSHi extension before it parses the content to achieve this:
Using syntax highlighting on Organic Design wikis
Blocks of source code can be wrapped in language tags like usual, as follows:
<php>
print "foo";
</php>
but also template syntax can be used to make the entire article be rendered by the GeSHi parser. The templates expand to nothing, so they can be placed anywhere in the article without affecting its execution (if the raw article is requested, templates=expand will need to be included in the query-string to make the template reduce to nothing). It's probably best to put the template in a comment so that the execution is not affected even if templates do not expand. Here's an example:
# {{per1}}
print "bar";
Technical
To get around these issues, I've added a few extra lines after the GeSHi include to allow the tags to be added before parsing if a language template is transcluded. Here's the additional code which as added at the end of the GeSHiCodeTag.php file.
include('extensions/geshi/GeSHiCodeTag.php');
$wgHooks['ParserBeforeStrip'][] = 'GeSHi';
function GeSHi(&$parser, &$text, &$strip_state) {
if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'raw' || $_REQUEST['action'] == 'xml')) return true;
if (preg_match('/\\{\\{(xml|bash|php|perl|c|r|as|js|css|sql)\\}\\}/i',$text,$m)) $text = "<$m[1]>\n$text\n</$m[1]>";
return true;
Templates or variables must be added which expand to nothing so they don't render as a red link. Also an extra line must be added to the GeSHiCodeTag.php file just before the geshi object is instantiated in the hook function to force the templates to expand.
$source = trim($GLOBALS["wgParser"]->replaceVariables($source));
The end of the function needs to have a hack added to remove some spurious <'s and >'s that crop up on transcluded code:
$text = $geshi->parse_code();
$text = preg_replace("/&([lg]t;)/","&$1",$text);
return $text;
Bugs
The geshi syntax highlighter has a language called <div>, this interferes with any wiki site <div> tags. To suppress this bug either delete the language file, of rename it to <div-lang>.
See also
- GeSHiCodeTag Extension - the GeSHi extension which worked most easily for us
- GeSHiCodeTag.php - the code with adjustments added