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.

Sokote zaman (talkcontribs)


I use this template:

<div style="overflow-x: auto;">
<div style="padding: 8px 20px;margin-bottom: 25px; text-align: {{{align}}};direction: {{{ltr}}}; clear: both; box-shadow: none!important; overflow-x: auto; background-color: none;"><h3>{{{title|}}}</h3>
 <!--[[Image:Crystal Clear action apply.png|25px]]-->
|{{#tag:syntaxhighlight|{{{source|{{{1|}}}}}}|lang="{{{lang|html}}}"|highlight="{{{highlight|}}}"|enclose="div"|line="y"|style="border-left: 4px solid #4CAF50; background: none;"}}
|{{#tag:syntaxhighlight|{{{source|{{{1|}}}}}}|lang="{{{lang|html}}}"|highlight="{{{highlight|}}}"|enclose="div"|style="border-left: 4px solid #4CAF50; background: none;"}}
<div style="text-align: right; clear: both;">{{Clickable button 2|{{{textbutton|مشاهدهٔ نتیجه »}}}|class=mw-ui-{{{colorbutton|progressive}}}|url=https://wikicod.ir/tryit/?file=/{{{dars|}}}/{{{link|}}}&type={{{output|client}}}}}

But after the article in the source section, for example:

<!--This is a comment. Comments are not displayed in the browser-->

<p>This is a paragraph.</p>

I put, the output shows only this:

<p>This is a paragraph.</p>

And does not show this part:

<!--This is a comment. Comments are not displayed in the browser-->

What is the problem?

Thank you for your help


PerfektesChaos (talkcontribs)

Two issues at first glance:

  1. Please omit quotes when providing wiki parameters, they will be put around again: |lang={{{lang|text}}}
  2. If the comment is really part of the source input, it will be displayed. However, I guess it will we removed already when you provide your input. You will need some smart method for encoding to keep it alive.
Sokote zaman (talkcontribs)

Thank you for your reply

I " picked the quote

Did not matter and re-show comments in the output

If possible explain more


PerfektesChaos (talkcontribs)
  • You are feeding your template from somewhere.
  • When you are providing parameter values, any comment will be removed and the template or module code will never ever know about that comment.
  • When you are feeding your template code, it will not know about any comment.
  • You need to escape e.g. the leading < but resolve that before further processing. Not easy and not possible to explain here since quite tricky.
Tacsipacsi (talkcontribs)

(edit conflict) When you use the {{#tag: form, the wikitext is preprocessed before passing it to SyntaxHighlight. This includes substituting template parameters, which you want to take advantage of, but also includes removing HTML-style comments (just like they are removed from the HTML output). I found that <nowiki/> can be used to prevent them from being processed as comments:

{{Template|source=<!-<nowiki/>-This is a comment. Comments are not displayed in the browser-->

<p>This is a paragraph.</p>}}

(I’d probably “break” the closing --> as well: while it’s not needed for this example to work, not “breaking” it can lead to unexpected results when one wants to comment out this part of the article.)

Sokote zaman (talkcontribs)


Thank you for your guidance

My problem was solved

Thanks & Regards

Reply to "not show comment"
Tacsipacsi (talkcontribs)

@Dinoguy1000: <source> is deprecated, but not removed yet. I think it should not be removed from the documentation as long as it works—feel free to add a huge warning advising users not to use it, but not mentioning it while it’s still used on all over Wikimedia creates even larger confusion than what was before. For example a user may wonder why a page ends up in Category:Pages with syntax highlighting errors when there’s no <syntaxhighlight> on the page at all (only <source> tags); if <source> is also mentioned, it’s more clear the two are synonyms (at this time).

Dinoguy1000 (talkcontribs)

It is still mentioned, at the end of the "Usage" section. I don't believe, given its current status and pending removal, that more than that mention is warranted (though the tracking category that gets added when it's used should be included).

Prod (talkcontribs)
Verdy p (talkcontribs)

Please don't remove the "source" alias, before letting the extension generate a tracking category, and allow tracked pages to be updated.

The problem is that "source" is much easier for most wiki users, that have difficulties to properly get the orthograph "syntaxhighlight" (or is it "syntaxhilite"?) without typos (and what is the correctc capitalisation between the two words?) May prefer "source", which is evident (don't be limtied to the fact that internally you use some highlighting library like GeShi or other, that uses the term "highlight" or "hilite"). So there are in fact MORE needed aliases with the "syntaxhighlight" term (which is very errorpone), but none for "source", which is definitely the best choice and should be the canonical name of the tag in MediaWiki ("syntaxhighlight" is a legacy).

If "source" does not make evidence that the source code will be highlighted (or because it has another use in HTML5) or this is indicating source code, then use "beautify" or "colorcode", or "programming" which also makes more evident that the parameter "lang" is not specifying a humane language (BCP47) but a programming language or just "syntax" (drop the term "highlight" kept only as a legacy alias); or support it only as an extended attribute of the "code", "tt", or "pre" elements (but then change "lang" parameter name into "syntax" or "as" for the XML-like syntax of this extension):

<code #tag:syntax:as="C">some code in C</code>
{{#tag:syntax|some code in C|as=C}}

(I wonder if MediaWiki supports hooks for custom attributes in the HTML/XML-like syntax, instead of just custom elements).

And note that there's still the problem of the unsafe embedding for the source code (see the other message about HTML-unescaping, which is needed to avoid havoc with the wiki parser, falsely interpreting the source code and modifying it)

Pppery (talkcontribs)
Tacsipacsi (talkcontribs)

@Dinoguy1000: I think it’s much more confusing for readers for the time being; especially for those who get there using a section link like Extension:SyntaxHighlight#Syntax highlighting error category. I don’t think it makes sense to remove references for it everywhere (I’m speaking about such documentation pages, not actual usage, of course). The deprecation notice could be made more prominent (like adding a colored box on the top of the page), but that’s all. And if you think keeping them will make replacement bots more complicated, you’re wrong—they should be made more sensitive anyway to stop doing replacements like the one I reverted here<source> is in nowiki, and has nothing to do with the SyntaxHighlight extension at all…

@Verdy_p: See phab:T251116; further discussion about whether removing <source> is a good idea or whether there should be another short name is off-topic here.

Verdy p (talkcontribs)

Note that the addition of the tracking category is very recent (I did not see it until very recently, this was not announced and I do not see it on every wiki, so the "deprecation" was decided by developers even if this was annouvned as their "intent" a long time ago. But the change to use "syntaxhighlight" only was never voted, and it is a nightmare for most editors, so the prefered name chosen is really on topic: ir could have just been "syntax" or we could have just used a "namespaced attribute" to standard HTML "pre", "tt", "code" tags, like " ... ).

As well you kept the non-conforming use of the required lang="*" attribute (whose value is not the BCP 47 language tag, but a symbolic name for the programming language, but could also have been the type="*" attribute like for standard "script" elements)....

The reason for the deprecation of the "source" element is also very fuzzy/doubtful:

  • we are actually NOT parsing HTML5 input, we just parse a MediaWiki syntax (that will then be used to *generate* HTML5) which has its own rules for acceptable elements/attributes and acceptable rules for self-closing tags, plus it adds its own private tags that are not HTML5 and the extra wiki-specific syntax for lists, tables, wikilinks and a few styles (bold, italic, monospaced blocks, and headings). There's absolutely no need for the Mediawiki text to be HTML5 compliant: it has never been compliant with HTML, and it will never be (unless we abandon the Mediawiki syntax completely for editing pages in pure HTML5, but then how will we even support templates or even this syntax coloring extension?).
  • we still don't accept random HTML5 input, so we still don't support on input any newer semantic elements like "heading"/"section"/"footnote"/"summary"/..., or and not even some older but standard and non-dangerous useful elements from HTML4 like "colgroup" (wanted since long!), or "thead"/"tfoot"/"tbody"/"rowgroup"...
  • The only convincing reason for deprecating the "source" tag is that because you want to add it to Mediawiki so that it will match the HTML5 semantic tag. But why only this one? Why we still don't have "colgroup"?

Clearly the deprecation anticipates a possible future change that has not even been prepared and fully designed, never been discussed (for its scope of application). For now there's clearly no need at all. And the replacement tag proposed is horrible to type for most people and its current full name was not approved by anyone.

Such deprecation just annoys people needlessly (just like the previous deprecation of self-closing tags when tags may have no content (like <s id="x"/> like in the XHTML standard syntax, which is shorter and simpler than <s id="x"></s> to place a content-less anchor on a page: you've created unnecessary work on every reviewers to maintain lot of pages without any added benefit)

Dinoguy1000 (talkcontribs)

@Tacsipacsi: mentioning source without including the fact that it is deprecated and soon to be removed, at every mention, is unacceptable. It doesn't matter if one mention of it does specify that, if any others do not, especially if they're on a completely different part of the page. This is plainly and clearly demonstrated by the fact that the page has listed source as "discouraged" since May 2009, and yet, over a decade later, it's still used so widely as to require a full and proper deprecation period, including tracking category and bot runs to clean up.

Adding an ambox at the top of the page isn't going to do much either; Wikipedia's extensive use of them for article issues has successfully trained people to ignore them, exactly the same as banner ads from past decades did for getting people to ignore any banner-style image elements on web pages.

Any further mentions of source that are added to this page must be clearly in the context of its deprecation and eventual removal, so there is absolutely no ambiguity about whether it should be used, especially for people who arrive at the page via a deep-link directly to a section.

Tacsipacsi (talkcontribs)

So what about writing

<syntaxhighlight> or (deprecated) <source>

(listing <source> second everywhere; probably without the parentheses)? That would keep the references, but it would make clear deprecation is now a real thing. (And I think a banner is worth adding in addition to other notices, including this parenthesized one—probably not everyone will notice it, but it still helps the people who do.)

By the way, I don’t interpret that 2009 wording (which was used till this April) that the short name was discouraged. This wording states that the long name “may help avoid conflicts if your source code itself contains <source>”—most source codes don’t contain <source>, in which case (in my interpretation) this sentence doesn’t encourage either tag name over the other. (This is why I happily used the short version for years even though I knew about this part of the documentation.)

Dinoguy1000 (talkcontribs)

I just don't see the benefit on including a mention of source with every mention of syntaxhighlight. Other deprecated markup doesn't get this treatment. If the deprecated tag is mentioned every time the current tag is as well, it makes it sound like the documentation doesn't really think the tag should be deprecated, and encourages confusion and doubt in readers. To flip this on its head, the documentation used source largely without mention of syntaxhighlight for over a decade, and to my knowledge, no one complained about it. Why is it suddenly so important that we do the opposite?

The full wording is "In older versions [...] the extension used [...] This is still supported, but [...]"; this has always read to me as a clear discouragement of using source.

Tacsipacsi (talkcontribs)

I don’t know what happened for over a decade and I don’t know when this over a decade was (my diff link above shows a state where the two were already equally represented). I’m not aware of any other deprecated markup either. I just see the current changes and would like to keep as much information as possible as long as it’s relevant (which is until it’s finally and fully decommissioned). But I see I won’t succeed…

Reply to "Mention of <source>"

Expanding templates/preprocess wikicode before syntaxhighlight?

Summary by

IP is trying to do something that SH doesn't have the functionality to do due to the nature of the implementation. (talkcontribs)


I'm using several nested templates within SyntaxHighlight v2.0 on MediaWiki v.1.33.3 to try to create a shallow documentation generator. So far, I have an template feeding inputs into another template that calls syntaxhighlight. My problem is this: I'm trying to create links within a syntaxhighlighted code block that allows for external links, by calling another template within it. Is this possible within this extension? I've been trying to play around with it for a few hours now, to no avail.


PerfektesChaos (talkcontribs)

Basically, you can do that and it is done already on wikis by template transclusion stack.

You will need syntax {{#tag:syntaxhighlight|1=code|lang=xyz}} and {{!}} to escape pipes. Good luck if double }} occur in your program code at the same level. Content and sections of other pages may be transcluded.

Basically the feature is dedicated to illustrate encyclopedic articles by static code snippets. A very sophisticated dynamic transclusion system might require advanced knowledge of wiki programming. (talkcontribs)

Thanks for the response. My knowledge of MediaWiki's inner mechanics is very superficial, I mostly use templates and the odd Lua script. I would link my existing template if I didn't trip the abuse filter. I should have been a bit more specific on the implementation - rereading it now, it's kind of vague (or I'm not understanding how to implement what I want)

Just to make sure I understand, given the following (omitting more complicated parts to just get to the crux of what I'm trying to do):

  • a "link" template that takes an input and returns something like [whateverurlhere?search={{{1}}} {{{1}}}]
  • a template that has feeds one or more of the above to syntaxhighlight

would create the following, given an input of test

{{#tag:syntaxhighlight|[whateverurlhere?search=test test]|lang=c#}}

How would I escape the provided first parameter to be processed as wikitext, instead of appearing verbatim? Apologies if I'm being dense, or going about this the wrong way.

PerfektesChaos (talkcontribs)

If you are using Lua anyway, I would recommend to use frame:callParserFunction( "syntaxhighlight", { [1] = "printf(%"Hello world%")", lang = "c#" } )

For template syntax, the part in between will be evaluated wrt double or triple brackets.

  • You might try to escape by <nowiki> if brackets indicate a URL.
  • However, that URL would not be linked, since it has single brackets and those are passed as parameter 1= to syntaxhighlight and that is hiding it from being evaluated.
  • You may put other wikitext as 1=code parameter, e.g. template transclusions or transcluding sections from other pages.
  • The major problem is if there is a pipe symbol | occurring in your c# code, e.g. bitwise or / || or. Those need to be escaped by {{!}} otherwise it will terminate that source code parameter if present at the same level like the #tag: function. If transcluded from somewhere else, as parameter value or result of any other thing, it does no harm.
  • Value of {{{1}}} will be shown as current value (being replaced by current content).
  • The inner parameter value of 1=code is evaluated first, until next | or }} visible at the same level, then #tag: will be evaluated with that string.
  • Pipes within complete template transclusion or complete internal link are assigned to those wrapping elements, they do not influence #tag: evaluation.
Pppery (talkcontribs)

I don't think you understand what the IP is asking; they want to post-process the output of <syntaxhighlight> to, for example, add links to it, which I don't think there is any supported way of doing that, although I can think of a very hacky way. (talkcontribs)

Just to provide context before I'm able to start hacking away at it - here is a snippet of the template.

{{Code/Pre|lang={{{lang|}}}|{{#if:{{{modifier|}}}|{{{modifier|}}} |}}{{#if:{{{keywords|}}}|{{{keywords|}}} |}}{{#if:{{{type|class}}}|{{API/ref|{{{type|class}}}}}{{#if:{{{generic|}}}|| |}}|}}{{#if:{{{generic|}}}|<{{{generic|}}}> |}}{{#if:{{{name|}}}|{{{name|}}} |}}{{#if:{{{parent|}}}|: {{API/ref|{{{parent|}}}}}|}}{{#if:{{{parentGeneric|}}}|| |}}

Aside from potential refactoring and code shortening (trying to get this to work before anything else), Code/pre is a template containing the SwitchHighlight call and API/ref is a template containing a switch statement with a link to a search query for external docs, or an internal link to a page (which is where I currently am in trying to add hyperlinks using wikitext). I'm trying to get the type identifiers to be searchable for faster navigation between documentation pages. All the nowiki tags are for syntax purposes and will be replaced later. Based on what I understood from PerfektesChaos, the URL can't be linked in the way I am attempting to do it as it all becomes evaluated by a template.

PerfektesChaos (talkcontribs)

The URL wouldn’t be clickable since it is displayed as text, and whatever you are feeding into syntaxhighlight is shown as source code rather than active element. That is the rationale behind syntaxhighlight. If you want to get a clickable URL you need to place an external link out of the syntaxhighlight region, e.g. using a table.

An entirely different approach would be a JavaScript gadget which is to be started by some miracle when that page is displayed, and which could read any element content, find some hidden URL and equip any element with a listener for a click. (talkcontribs)

Alright. Thanks for the help, I'll look for another avenue to try to get this functionality implemented.

Reply to "Expanding templates/preprocess wikicode before syntaxhighlight?"

safe highlighting of source code: how to HTML-unescape character entities?

Verdy p (talkcontribs)

When we use either the XML-like syntax, or the #tag syntax, we have a problem to embed source code which is NOT using the wiki markup language (i.e. the source language is NOT "html")

Some characters in the embedded source code will cause

  • either the XML-like syntax to be terminated if the source code contains any occurence `</source>` or `</syntaxhighlight>`
  • or the #tag: syntax will break if the source code contains any vertical bar (`|`).

The temporary solution (if the source code is in the same page and not transcluded) is then to:

  • for the XML-like syntax, HTML-escape the problematic characters `<` or `&` by a numeric character entity `<` or `&`; however the syntax highliter, when called with the XML-like syntax, does not properly unescape them to get the raw character.
  • for the #tag: syntax, escape the problematic characters `|` by an HTML-escape like `&124;`.

The problem is that this does not work: the extension still does not unescape the source code given.

It is then impossible to properly transclude the source code from another page (using `{{msgnw:Full:Pagename}}` which generates lot of numeric character entities, that are still not decoded.

We should have either a parameter for the syntax highlight extension, instructing it to unescape all character entities present in the given source code, or another variant of the tag, where this instruction is explicit.

Without proper HTML-unescaping, this extension does not work properly: some source code will break either the parser, or will cause the MediaWiki parser to interpret and modify the source code (when using the #tag: syntax instead).

Can such option be added to this extension tag, as an optional parameter like `|unescape=yes` (when using it with the `#tag:` syntax, notably when the source code is transcluded by msgnw from another page) or `unescape="yes"` (when using it with the XML-like syntax)?

Useful examples of use (with safe transclusion of source code from another page, using msgnw):

  • {{#tag:source|{{msgnw:Full:Pagename}}|lang=html|unescape=yes}}
  • {{#tag:source|{{msgnw:Template:Templatename}}|lang=html<!--or mediawiki?-->|unescape=yes}}
  • {{#tag:source|{{msgnw:User:Someone/foo.c}}|lang=C|unescape=yes}}
  • {{#tag:source|{{msgnw:Module:Pagename}}|lang=lua|unescape=yes}}

Alternative (or addition): don't embed the source code in the content of the tag, pass the name of a page to transclude (it would be more efficient as there's then no need to first HTML-encode the transcluded source code with msgnw, then unescape it in #tag:source; instead #tag:source will just read the raw content of the page, without passing it throught the wiki parser):

  • {{#tag:source||page=Full:Pagename|lang=html}}, or
    <source page="Full:Pagename" as="html"/> with the XML/HTML like syntax
  • {{#tag:source||page=Template:Templatename|lang=html<!--or mediawiki?-->}}
  • {{#tag:source||page=User:Someone/foo.c|lang=C}}
  • {{#tag:source||page=Module:Pagename|lang=lua}}
Pppery (talkcontribs)

You can work around the limitations of the #tag method by escaping the vertical bar as {{!}}, instead of using an HTML entity.

Verdy p (talkcontribs)

No, it does not work (I've tried), and certainly not for simply trancluding the source from another page/subpage.

It makes editing wiki pages containing source code very complicate if we need to check every character used in that language. And there's still no way to prevent MediaWiki to transform the source code, even if this is not using the Mediawiki syntax (e.g. it could be Lua code, C, C++...)

And this does not work if this if for embedding some source code in an review wikipage presenting the code used in some external page: the source code is edited independantly of the review wikipage, it may be blocked from editing while the review page open for talks/comments.

What you suggest are compliate "hacks", it would just be simpler to support unescaping or direct transclusion by this extension tag: users will provide their source code in a page or subpage (or a Lua module, or a CSS stylesheet page), and will reference that full page name.

PerfektesChaos (talkcontribs)

BTW, please note that source is obsolete for 8 years now and will be replaced by syntaxhighlight entirely; that means: no support for <source> any longer in near future. It is throwing maintenance categories already.

The method is dedicated to show code exactly as-is; that does mean: it is not supposed to “properly unescape” but to reproduce that entity source code.

Verdy p (talkcontribs)

Yes I know, I've used "source" but my comment is completely valid as well with the "syntaxhighlight" keyword (so horrible that many have difficulties to type correctly, or remember...)

  • Adding the "unescape" parameter has the demonstrated use (safe transclusion, and simpler editing of source code in a separate page/subpage, possibly in a dedicated namespace with a better editor like the Lua source editor, or a CSS editor; the wiki editor is not fun for editing C, C++, Lua, CSS, or raw HTML code, or other markup languages like BB-code).
  • Adding the "page" parameter (to replace the content parameter 1 which will be then ignored or just prepended to the transcluded page) makes all this also simpler for users (no need to know the "msgnw:" transclusion mechanism and its caveats), and much more efficient (transclusion with "msgnw:" is very costly in memory terms of generated text length because of the many HTML-escapes spread everywhere! Newlines, tabs, almost all ASCII punctuations are HTML-escaped; only letters, digits and a very few symbols like ".", or non-ASCII characters are not HTML-escaped by "msgnw:" tranclusion). "msgnw:" has no practical use, and should be deprecated (really too costly and impossible to process simply in any Wiki template, even if it may be processed in Lua performing the needed unescaping and using the #tag extension directly without returning to the wiki parser)

Many community wikis have strongly rejected the suppression of the "source" name (or alias), they don't like the "syntaxhighlight" name that they can't memoize and type correctly (and which is overlong). Unless you propose a better name (a single word please, like "syntax"!), "source" is there and will continue to be widely used in many wiki pages.

There's more urgent useful thing to do than rejecting "source". Notably "lang" conflicts with HTML as well as it does not indicate a BCP47 language code and it causes confusion! Note that some programming languages have linguistic variants (e.g. Excel formulas: syntax="excel" lang="fr", where "IF(condition;value1;value2)" in English Excel must be rewritten "SI(condition;valeur1;valeur2)" in French Excel...) As well lang="*" would be useful for indicating the human language used in text litterals of the programming language, to allow a spell checker to scan these litterals; the litteral values will be given to the spell-checker by the syntaxic parser, the spell-checker needs no parsing of the syntax of the programming language; the spell-checker may as well be hinted, i.e. "in which language are the litteral values that the spell checker will process", by directives detected in the source code by the program parser).

For the related (but different) HTML element "script", the programming language (for the embedded source code which is not rendered but executed) is indicated by a "type" attribute, not "lang". This should be the same for the "source" extension tag, aka "syntaxhighlight", aka "syntax", aka "program" or the simple name you would choose for the XML-like syntax; the name used for the "#tag:" syntax however is not relevant and does not need to remove "source" as there's no conflict with XML/HTML asn the "#tag:" syntax already isolates it in its namespace. For the HTML/XML-like syntax, the extended tags should have better used the "tag:" namespace since the begining, in which case there was no problem with <tag:source type="C">...</tag:source> or <tag:code type="C">...</tag:code> OR <tag:pre type="C">...</tag:pre> or <tag:tt type="C">...</tag:tt>... not to be confused on some wikis like the OSM wiki, where the prefix "Tag:" is also used to name pages or Mediawiki namespaces for page titles).

PerfektesChaos (talkcontribs)

(other message crossed) There is no exception than escaping pipe (and perhaps }} terminators) of the code parameter.

I am doing this for quite a long time, and there is no problem at all if you embed static code into <syntaxhighlight> tags. If you want dynamic embedding of external things than you are running into a philosophical problem: You need to be clear what the code is that you want to be presented, and where and how you make the distinction against the code triggering the dynamic transclusion effects but shall not be visible and shall be interpreted.

I do not type <syntaxhighlight>, never, I use C&P or editing tools for insertion.

Verdy p (talkcontribs)

You can do this only within the same wiki page. This is still horrible and complicate, very errorprone. This is impossible via transclusion (which is definitely simpler for all users, given they can edit their code separately in a better editor for the programming language, than the default wiki editor)

For example we have a Wikitext editor (along with its visual editor) for wiki pages, a CSS editor, a Lua editor. We could have dedicated editors for data (e.g. CSV or tabulated, or JSON), C/C++, PHP, Javascript, Java, XML, SVG... These editors will internally also embed their syntax highlighter (probably the same as the one use with the source/syntaxhighlight tag in Madiawiwiki pages, i.e. GeSHI or Pygments.

Reply to "safe highlighting of source code: how to HTML-unescape character entities?"

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>?"