The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
Change-Id: Id89128fd4da73a71ac818d1943fe172f20b07938
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: Ic848fa4ffdeccb8340d347aeb23216364238501d
We cannot set this in the normal "require-dev" because the plugin
depends on exactly PHP 7.0, preventing running tests on any other PHP
version.
Instead, CI will read the version number out of the "extra" field to
figure out what version to install.
Bug: T187497
Change-Id: I36cb5e14e740afabdd42a04ff19b6d59a59a502e
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
The following sniffs are failing and were disabled:
* MediaWiki.Files.ClassMatchesFilename.NotMatch
* MediaWiki.Files.ClassMatchesFilename.WrongCase
Change-Id: I2781f52be104163ba58e30055bc7593da6ded29a
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPublic
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment
Change-Id: I6f0b55e7694cdae1fcdd68b33449db412a656e37
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
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
