Extension talk:BacktickCode
Adaptation notes
editI 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);
Compatibility with Mediawiki 1.27.0
editFor 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
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)
<?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
editThe 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
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.
46.130.146.196 08:28, 3 September 2016 (UTC)
Wait why? Is familiarity / interoperabiltiy a bad thing?
FYI - I am working on packaging this for Fedora
editMy 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?
editI'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)