Extension talk:BacktickCode

From mediawiki.org
Jump to navigation Jump to search

Adaptation notes[edit]

I adapted this extension for the ConTeXt wiki, so that it would also leave alone backticks inside ‎<texcode>...‎</texcode> and ‎<context>...‎</context> tags. Things to take into account when adapting:

  • The current regex is case-sensitive: f.ex. ‎<pre> is matched and backticks inside it are ignored; if the tag is written ‎<PRE>, this does not happen..
  • The current regex does not match tags with attributes. We discovered this when our adapted version properly matched and ignored the contents of ‎<context> tags, but did not ignore backticks inside ‎<context source=yes>.

Adapted code that allows tag attributes (but is still case-sensitive):

$text = preg_replace_callback('/(<context[^>]*>)(.*?)<\/context>/s', function ($match) {
    return $match[1] . preg_replace('/`/', '\`', $match[2]) . '</context>';
}, $text);

--Sietse (talk) 22:39, 30 May 2013 (UTC)

Compatibility with Mediawiki 1.27.0[edit]

For some reason this extension will not work with Mediawiki version 1.27.0,

when used, all text is will be garbled with "uniq" (prefix) "qinu" (suffix).
seems to be a parsing problem:

BackTick/BackQuote/Grave seems to work in MediaWiki out of the box

This Code works for me[edit]

This didn't work for me, I still got QINU, until I removed the require_once in LocalSetting --JimmyRoxburgh (talk) 03:15, 19 August 2016 (UTC)
Update: Actually it stop replace backticks, so i put the require_once back in - and it is now working, no QINU. I suspect a rebuildall helped --JimmyRoxburgh (talk) 00:19, 23 August 2016 (UTC)

class BacktickCode {

    public static function onParserBeforeStrip(&$parser, &$text, &$strip_state)
        $text = preg_replace('/([^\\\\]|^)`([^`]*)`/', '$1<code>$2</code>', $text);
        $text = preg_replace('/\\\\\`/', '`', $text);


// Running MediaWiki?
if ( defined( 'MEDIAWIKI' ) )
    // Register our MediaWiki parser hooks
    $wgHooks['ParserBeforeStrip'][] = 'BacktickCode::onParserBeforeStrip';

} // End MediaWiki env
    die("This is an extension to the MediaWiki package and cannot be run standalone.");

The root cause, and another solution[edit]

The problem with the above solution, i.e. running it on the ParserBeforeStrip hook, is that backtick pairs inside <nowiki> blocks may still get processed.

The root cause of the whole thing is that the parser marker prefix and suffix (Parser::MARKER_PREFIX, Parser::MARKER_SUFFIX) contain backticks themselves, if you look closely: `UNIQ, QINU`. If you run the backtick filter before stripping, you get around that problem but you break nowiki tags.

So here's a version which respects nowiki tags. It runs on the InternalParseBeforeLinks hook, after <nowiki> blocks are protected, and it's smart enough to not mangle the marker affixes (or rather, it mangles them and then unmangles them ...)


 * @author Joel Thornton <mediawiki@joelpt.net>
 * @license http://www.gnu.org/copyleft/gpl.html GNU General Public License 2.0 or later

    die("This is an extension to the MediaWiki package and cannot be run standalone.");

class BacktickCode {
    public static function onInternalParseBeforeLinks( &$parser, &$text, &$stripState ) {
        // We replace '`...`' by '<code>...</code>' and '\`' by '`'.

        // This is hard, because MediaWiki itself uses backticks in
        // the `UNIQ and QINU` blocks.  We find that when we just
        // change pairs of ` `, we break the stripstate badly.  So
        // first we're going to "hide" those by turning the backticks
        // into tildes.
        $fixprefix = preg_replace('/`/', '~', Parser::MARKER_PREFIX);
        $fixsuffix = preg_replace('/`/', '~', Parser::MARKER_SUFFIX);

        $text = str_replace(Parser::MARKER_PREFIX, $fixprefix, $text);
        $text = str_replace(Parser::MARKER_SUFFIX, $fixsuffix, $text);

        // Now that those are tildes, we can do the replace.  We check
        // for \x7f to ensure our pair of backticks isn't spanning a
        // UNIQ/QINU set.
        $text = preg_replace('/([^\\\\]|^)`([^`\x7f]*)`/', '$1<code>$2</code>', $text);
        $text = preg_replace('/\\\\\`/', '`', $text);

        // Now put the prefix/suffixes back to normal.
        $text = str_replace($fixprefix, Parser::MARKER_PREFIX, $text);
        $text = str_replace($fixsuffix, Parser::MARKER_SUFFIX, $text);

        return true;


    "name": "BacktickCode",
    "version": "1.0",
    "author": [
		"Joel Thornton"
    "url": "https://www.mediawiki.org/wiki/Extension:BacktickCode",
    "description": "Allows to show text as <nowiki><code></nowiki> between backticks (`)",
    "type": "parserhook",
    "AutoloadClasses": {
	"BacktickCode": "BacktickCode.php"
    "Hooks": {
		"InternalParseBeforeLinks": [
    "manifest_version": 1

Hope this is both useful and instructive. Sk4p (talk) 15:19, 15 October 2016 (UTC)

This is wonderful! Have you considered updating the extension page or making your own for this? James Kevin Martindale (talk) 04:57, 23 October 2016 (UTC)

Backtick code is same as Markdown[edit]

Ћ Back-tick code and Backslash escape is same as Ћ Markdown’s syntax. Can we have something like ``Code`` (with two back-ticks/graves), and \\Markup ''can’t'' be formatted\\ (using two backslashes for a replacement of <nowiki> tag. 08:28, 3 September 2016 (UTC)

Wait why? Is familiarity / interoperabiltiy a bad thing? 19:27, 16 February 2017 (UTC)

FYI - I am working on packaging this for Fedora[edit]

My mw profile has my email if anyone wants to get in touch. I am sending an email to the author credited.

— Preceding unsigned comment added by Aikidouke (talkcontribs) 07:39, 29 June 2018

Does this still work?[edit]

I'm running Mediawiki 1.32.2 on PHP 7.3.6 (fpm-fcgi). I am not seeing the behavior that backticks work out of the box....

I want this functionality, and have tried all of the various versions listed (including the one on the main page, and the two solutions above on the talk page, and a couple from 2018 in the page history), and haven't been able to get this to work. Am I missing something?

Bravemidwesterner (talk) 01:38, 19 July 2019 (UTC)

@Bravemidwesterner: The one on the extension page and the one above here on the talk page both work for me. I think there are issues with them both, but they do function to some extent. What error are you seeing? Sam Wilson 06:44, 19 July 2019 (UTC)