This way, a visit by a logged-in user to a page with stale syntax highlighting
will also trigger a purge of the page for anons in Varnish.
Change-Id: I366563839c89d9546447d3e58bb9239a36bf70bd
I'm not entirely sure that this will always behave correctly on RTL
wikis, but currently we never behave correctly on RTL wikis.
Bug: T85794
Change-Id: I8af2b18884ec619d581f9ceed737c5628b647086
* Don't json_encode() the whole code block, that's stupidly expensive when the
code is a string already. It's only the options array that needs to be
explicitly stringified.
* Incorporate a cache version parameter input in the cache key so we can manage
changes to the extension's HTML output.
* Only use wfGlobalCacheKey if available, to maintain 1.25 compat.
Change-Id: I8d536f9011763f47667502225ed4459be7d2ed4a
Remove trailing \n after closing </div>, as it results in multiple
newlines that confuse the MediaWiki parser into generating <p><br></p>
all over the place.
Bug: T85794
Change-Id: Iffaa73b49c29e94d8a1a659dd40b845a9f4ce0c1
It was always "none" and not "span", this must've been an accidental change.
Also add a CSS tweak to better render the common pattern of
<code><syntaxhighlight enclose="none">...</syntaxhighlight></code>.
Bug: T85794
Change-Id: I3ed1b7f3c954374b49fc9a97881ea5236415cb6f
* Restore parseHighlightLines() function from before
6484894497, which introduced a
regression in parsing line ranges. There are no tests for this and
I'm not going to debug the regexes.
* Use a space rather than a comma as separator when passing the list
of line numbers to Pygments.
Bug: T85794
Change-Id: Ib86c216308a973000a4129c2c46286ec1dc988e1
Now that we switched to pygments, there should be mo reason not to
enable this on mobile
Bug: T100563
Change-Id: I008b71d4cef04fb7dc7c2ad574032f9c4645b063
Include Pygments 2.0.2 as an executable zip bundle. Also include a script to
automate the process of creating such bundles and to make it reproducible and
verifiable.
Change-Id: I67e6f804e493f065311164c610dc541a5779654e
If Pygments ever adds a dedicated lexer for 'cadlisp', for example, we'd want the
extension to use that, rather than use the compatibility map.
Change-Id: Icc610695ac2826bb526f7c69e867576c660ba6ef
GeSHi is unmaintained, lacks support for many popular modern languages, and
suffers from deep architectural flaws, chief among them the inconsistent
tokenization of different languages, each of which requires a custom
stylesheet.
Pygments is a well-maintained alternative. It is, by my count, the most popular
syntax highlighting library around. It is BSD-licensed, actively maintained,
and is widely used in PHP projects.
To keep this easy to review, this change does not include update for l10n
files, and it does not delete the geshi/ directory. I will do those in a
separate patch.
The chief change between this and the previous implementation is that errors
result in the code block not being highlighted, as opposed to not being printed
at all, having been replaced by an angry red error message. I think that is the
right user experience. If you go to StackOverflow or GitHub and try to mark up
your code block as being written in some language that their highlighter
doesn't know about, you don't get an error message -- the code simply doesn't
get highlighted.
Because we don't recursively load dependencies for extensions, to test this,
you will need to create a composer.local.json in $IP and add:
{
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json"
]
}
}
}
Then run `composer update`.
Bug: T85794
Change-Id: I07446ec9893fae3d1e394f435d3d95cf8be6bc33
'Fancy' line numbers are a fairly useless feature, not seen
in any other code highlighter. As the extension doesn't let you
choose a line number mode, default to normal.
Bug: T101602
Change-Id: Iccbd3ba6c91c58b0ea0f0c09832f1422936cd475
Geshi::error() is a method that returns an HTML string representing
the error.
Geshi->$error is an integer error code.
This code clearly means to compare against the integer code given that
GESHI_ERROR_NO_SUCH_LANG is an integer.
Verified by using eval.php to instantiate "new Geshi( '', 'js' );"
and $geshi->error:
> 2
but $geshi->error():
> "<br /><strong>GeSHi Error:</strong> GeSHi could not find the language"
Change-Id: I1ca77733d4b6b5481c5db6aba9f6b7dda6803099
Follows-up f37cee996e which replaced the getHashMtime() and
getDefinitionMtime() methods with dummies that always return 1.
These getModifiedTime() implementation was only tracking the
definition, which is already tracked by getVersionHash().
Bug: T94074
Change-Id: I6e37c3c2f85ef4599a8643b0efabc18de2f51ec4
Style modules currently added through addModuleStyles default
to being in the head ("top" position). This is an unhealthy default,
since only critical styles that are needed at pageload should be
in the head. In order to be able to switch the default to "bottom",
existing module positions have to be defined explicitly.
Bug: T97410
Change-Id: Ie120a781ac1950abd7963d6f722aa316b5542b51
Try #2. Our last attempt loaded $wgGeSHiSupportedLanguages late, and
would override anything if it was already set. We still load it late, but
only if it is not already set.
This reverts commit 033ca20746.
Bug: T88063
Change-Id: Iae0806e06a95b2d8932b3d9e078e6135dd6750a3
This should've been the case already and will result in an exception
otherwise in MediaWiki core as of Ibb292d2416839.
Change-Id: I062a224662823224f3104d9e8d05abce47b1da81
There are 100s of instances of this module. This can slow things
down quite a bit in Vagrant when it recomputes the same timestamp
many times.
Change-Id: Iaebafe1acf7a0e30ebf86179961ad52f56bb689f
