Commit graph

12 commits

Author SHA1 Message Date
zoranzoki21 55e9170492 Update Maintenance scripts in extensions to use $this->requireExtension()
Bug: T152139
Change-Id: I9aead5ae7106150dfae749a91b6b403c94811f3f
2018-01-28 16:42:01 +00:00
Kunal Mehta dc4e684056 Use shell restrictions to contain pygments
If enabled, apply the default restrictions and take away network access
from pygments.

Bug: T182468
Change-Id: I4e5a6e01a24229a3923642af8de880dbf9167562
2018-01-04 13:07:39 -08:00
Kunal Mehta 15b894bdbc Drop symfony/process dependency, use Shell\Command instead
We originally started using symfony/process because kzykhys/pygments
depended upon it. But that library was unmaintained and became broken,
so we stopped using it, and just used symfony/process directly.

At the time, the main reason in favor of symfony/process was that it
could pass stdin to pygments, while Shell\Command couldn't - but it can
now (T182463)! On top of that, there are downsides, like not respecting
the default MediaWiki shell limits, being incompatible with core's
firejail support, and requiring an external composer dependency.

Note that because Shell::command() will enforce MediaWiki's normal
limits, it's possible that some large pages may no longer render with
syntax highlighting if they pass those limits.

Bug: T182467
Bug: T181771
Change-Id: Ie1cb72b7eb17d943f79ecae4d94a2110546ef039
2018-01-04 13:07:35 -08:00
Rafid Aslam 46700b5fdb Add phan configuration for static analysis and fix phan warnings
Add phan configuration for static analysis, and fix phan warnings.
`PhanDeprecatedClass` and `PhanDeprecatedFunction` rules are supressed.

Bug: T179554
Change-Id: I7cbb410ed88ba58198d0557cafd9e6df968ed885
2017-12-25 11:16:49 +07:00
Umherirrender deb5fc0fcf Rename files to match classes
Change-Id: I6e66abdf4f0eff0a24b96e543f2ce8f293bb7860
2017-12-10 01:32:49 +01:00
Kunal Mehta 987187935c Make sure $wgPygmentizePath is sane only when we need it
This avoids having an extension function, which runs on every request,
regardless of whether it uses syntax highlighting or not.

Change-Id: I890348b73af956819300cce64d0672dcdb209c19
2017-07-06 00:57:40 -07:00
Umherirrender 038fde9ed1 Use short array syntax
Done by phpcbf over composer fix

Change-Id: I043252a1cce9e51f158e0e27983ed4ae18fcfb42
2017-06-15 18:16:11 +02:00
Derk-Jan Hartman 45e3085a59 Remove GeSHi from class and filenames
Remove the GeSHi name from filenames and classes where possible. We no
longer actually use GeSHi, and though we cannot rename the extension or
repo atm, we can rename these.

Bug: T164939
Change-Id: I02bc3304d88103c5302f203e788fc73ff20e1050
2017-05-20 14:47:23 +00:00
Ori Livneh c47fb10767 Remove duplicate values from the lexer list
Update the updateLexerList.php maintenance script so that its output contains
no duplicate values, and remove existing duplicates from the lexer list.

Change-Id: I1ee094bb73f1a3916530e533ba3d151e50b34ce3
2016-02-03 17:30:01 -08:00
Ori Livneh f89bc8d62c Drop dependency on kzykhys/pygments
kzykhys/pygments provides very little added value when compared to just using
symfony/process directly. Since kzykhys/pygments appears to be unmaintained and
is currently broken, depend on symfony/process directly instead.

Change-Id: I34c7e4201c2c21d3f8607ec826a4c9869e2da917
Task: T120068
2015-12-04 15:02:13 -08:00
paladox ee3896a51c Add php code sniffer to SyntaxHighlight_GeSHi
Requires https://gerrit.wikimedia.org/r/#/c/225035/

Change-Id: If46b56fa8aa26b03890274ac772110eba9519f8d
2015-09-27 21:16:58 +02:00
Ori Livneh 6484894497 Highlight using Pygments rather than Geshi
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
2015-06-22 23:37:15 +01:00
Renamed from maintenance/updateLanguageList.php (Browse further)