Follows-up 043969f84e.
This caused a fatal MWException when saving/reading pages that contain a
<source> that couldn't be highlighted (e.g. no lang attribute, unknown
lang, or too large).
Specifically when wgWellFormedXml=false, in which case $out isn't
just from Pygments, but actually from our own Html::element.
Change-Id: Ib299a274d28021b2c7bba52d763dd1e17c1f09ec
* Use 'nowiki' strip marker to prevent list processing (also known as
doBlockLevels()). This resolves various issues related to using
<syntaxhighlight/> blocks in lists and lists suddenly appearing
inside <syntaxhighlight/> blocks. Fixes T17333, T25674, T104067.
* To prevent <p/>-wrapping resulting from the above, add our own
wrapper <div/> around the output.
* Since we already have our own wrapper, remove Pygments' one and
extend it with custom attributes. This resolves some regressions
from the GeSHi migration. Fixes most of T103964.
Bug: T17333
Bug: T25674
Bug: T103964
Bug: T104067
Change-Id: I3afd1224a18549c62cd4a95fd046affa6d1d3b3f
Do this by having SyntaxHighlight_GeSHi::highlight() return a Status object
rather than a plain string, and by making it the highlight method's job to look
up a lexer for a language. The actual warning text is not outputted anywhere
yet; deferring that for a follow-up patch.
Bug: T103586
Change-Id: Id839f925a56ab09a8423958327b9aefd7207ef37
MZMcBride noticed the red border around '國' in
https://en.wikipedia.org/wiki/Swift_(programming_language)#Example_code
That particular case happens to be a Pygments bug, because multibyte characters
are valid variable names in Swift. But even in cases of legitimate syntax
errors, I don't think we want to show the red border. This behavior may be
useful in code editors, but it is not useful in a wiki environment, especially
given the longstanding habit of using an existing, mostly-compatible lexer to
highlight a language for which no specific lexer exists.
To fix this, override the style in pygments.wrapper.css, and swap the order in
which the two CSS files are concatenated, so that in general we have the
ability to override Pygments-generated CSS.
Change-Id: I304fdaf3a462445d316e0f7fecc983fa87afc629
This makes installation easier for local development.
Per https://www.mediawiki.org/wiki/Manual:External_libraries
I was supicious about whether 'use KzykHys\Pygments\Pygments;'
works in a file if the namespace/class itself is only loaded
later, but it works fine.
Ref T103890.
Change-Id: Ia1a577f555cd8ab09969dec219316bc1e76769f4
Before we started using the 'code' tag for inline code snippets,
<code><syntaxhighlight enclose=none ...>...</syntaxhighlight></code>
was a common pattern. Continue supporting it in existing content.
Follow-up to 04293baad9. My IRC comments
about this were seemingly forgotten, and the code I added in
5b7522a5fc to handle this problem
unceremoniously removed.
Bug: T85794
Change-Id: I8e52089fed41e78fb60ddd5b7c12075056265dd9
The 'direction' rules must not be applied to regular preformatted
text in MediaWiki core, only to syntax-highlighted programming
language code.
(Not reverting the part that removes 'monospace' rule, *that* is
superfluous.)
This reverts commit f834b719b9.
Bug: T103780
Change-Id: Ie7e9123ab3456aa6fff0485431fe81cd5eb31fa2
The styles in MediaWiki core for <pre> already cover this. And
for skins that want different styles, SyntaxHighlight should not
have been overriding it.
Bug: T103780
Change-Id: Ib863288a9a4530b183cf5fdb692489363d82a50f
It previously supported more values, but since the switch to Pygments
these additional values are no longer supported. It now always
outputs <pre> or <code>, not e.g. <div>.
Change-Id: I406eee0eeeb3b9aaec3fa464ffdf6e200c868b84
Pyglet is an internal web service that listens on port 31337 by default and
which accepts syntax highlighting request via POST. If $wgPygletURL is set to a
URL of a Pyglet instance, the extension will attempt to query the web service
instead of shelling out.
Change-Id: Ic49f4cd77585dbffc5392e80904754ff889b8a63
Until and unless there is an explicit need (and intent to support)
a public interface to use this data elsewhere, there is no need
for it to be a separate module.
It can be its own class, but at the resource level this data should
be considered a JavaScript file. And we don't create separate modules
for each file. They are in the same module unless they should be
semantically loaded in unrelated page contexts.
The module registery is not a javascript class autoloader. There
is a global cost to adding more modules to this registry.
Change-Id: Ifeddef8cfe00b6c115734f92eceab251a0b75bdb
Follows-up b403b58. When using the content to version the module,
no summaries or modified hashes are used. The content itself is
hashed to naturally invalidate stale cache.
Change-Id: Ic6a20274e19fcf48cb8fe2ef39e48feb7c456391
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
