Extension talk:BacktickCode

Adaptation notes

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

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:

• https://www.mediawiki.org/wiki/QINU_fix
• https://www.mediawiki.org/wiki/Thread:Extension_talk:Favorites/UNIQ...QINU_parser_problem

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

This Code works for me

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)

<?php

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
else
{
    die("This is an extension to the MediaWiki package and cannot be run standalone.");
}

The root cause, and another solution

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 ...)

BacktickCode.php:

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

if(!defined('MEDIAWIKI'))
    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;
    }
}

extension.json:

{
    "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": [
		    "BacktickCode::onInternalParseBeforeLinks"
	    ]
	},
    "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

Ћ 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.

46.130.146.196 08:28, 3 September 2016 (UTC)

Wait why? Is familiarity / interoperabiltiy a bad thing?

206.45.25.237 19:27, 16 February 2017 (UTC)

FYI - I am working on packaging this for Fedora

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 (talk • contribs) 07:39, 29 June 2018

Does this still work?

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)