Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I45053ede3898b5c886a8182659466d321126ac1f
This piece of code is only relevant in case when:
- the intro section is requested (either in plaintext or html);
- the parse result for the full page is available in the parser cache;
- the full extract is not available in the TextExtracts WAN cache;
- the intro is also not available in the TextExtracts WAN cache.
In this case getFirstSection() is called with the parser output,
which is different from the the convertText() output it is called
with in other code paths, and still contains <h*> tags. A quick
regex is used to extract the first section. This stops at any <h2>.
A TOC also contains a <h2> (which will be removed later via
$wgExtractsRemoveClasses). This one needs to be ignored in case
the TOC is placed before the first section using e.g. the __TOC__
keyword.
The patch changes the regex so it ignores a h2 with
id="mw-toc-heading", but keeps working in plaintext mode when <h*>
tags are not present (the code path when the intro section is
requested, and the full extract is available in the TextExtracts
WAN cache but the intro extract isn't).
Bug: T269967
Change-Id: I0a495d06cf1725744e556e81f17047fb53f53521
This avoids the user language to take effect on the parse,
it reflects more the anon part than just "new User()"
Change-Id: Ic6a4a81074a16b85ac2f1c7952f27a03a0c76dec
All services can be injected by bumping minimum
version of mediawiki (1.34 would be enough, but
since that is no longer supported require 1.35)
Change-Id: I8bb1573a02932ef5f2871606e94a41afe073fd00
When the text is short enough to be returned as it is, it's very
confusing to see it with an ellipsis added at the end. There is
no more text. It should not look like there is more text.
Change-Id: I7ef205fde6c358a1cbcbb41346a1c9e2a856d8fd
Don't warn if the limit is >1 but there's only 1 title to process
because there's nothing wrong with the current request.
Change-Id: Ia991e58420d31520cb83b24b1183d526fd79edb2
Remove use of deprecated MWTidy::isEnabled() and internal
MWTidy::singleton() methods. See I3584181070da7ed4888beaaf04e083114aca1eab
for context.
Bug: T198214
Change-Id: I511068cc7b2398773a837f66e08def206cbb5626
The way this test is set up means the $this->params property is not
initialized. It is only initialized when execute() is, well, executed.
Since there is not really a guarantee this will always happen before
the failing method is called, I figured it's better to add this cheap
safety check in the production code.
Taggign with T233012 because I believe this extension is a gated one
for many other codebases.
Bug: T233012
Change-Id: Ie0060125cf4646d80f8c88eedd01551f66e3fb89
composer:
* mediawiki/mediawiki-codesniffer: 28.0.0 → 29.0.0
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
npm:
* eslint-config-wikimedia: 0.12.0 → 0.15.0
* grunt-eslint: 21.0.0 → 22.0.0
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
* Removing manual reportUnusedDisableDirectives for eslint.
Change-Id: I351f0a333fd5f06e47f0748aa25cb3fff63cc67f
I argue that the code fixing unclosed HTML tags is – even if optional –
an integral part of the code that potentially breaks these HTML tags in
the first place. Notice how much code disappears in the ApiQueryExtracts
class.
Additionally, the new approach uses an interface instead of a static
function call that is impossible to mock and hard to test.
Change-Id: Ic1a65995f4dba11d060a8738d642905cbfc79271
Note how only two files mentioned the license before. For consistency
it should be either all or none. Both solutions would be possible. Even
*not* mentioning the license anywhere in these files would be fine from
a legal perspective, as long as the relevant file COPYING is still
there in the root folder of this extension.
The overly long "deed" text does not serve much of a purpose. It's not a
complete, legally relevant license text. It's hard to read as the fact
this is "GPL2+" is surprisingly hard to find. The @license tag solves
these problems, and is recognized by documentation generators.
Change-Id: I7844be0c5f4f3d7562156cd9f34fe466552a9c9d
This is a straightforward baseline patch that does nothing but moving
existing code around, without touching it. I'm not even trying to
remove the "static" keyword. The actual refactoring will be done in
the next patch. I hope with this the changes I do in the refactoring
become more visible and much easier to review.
Change-Id: Idba859ec0c24f3622ea8fb8d7a9b11843d1e3827
This gets rid of code that is reported as being unused, even if it is
used.
This also simplifies the regular expression a little bit. The .
automatically ends at the end of the line when the mode /s is *not* set,
which it isn't. The /m mode is not needed then because there is no ^ or
$ any more in the regular expression.
Note this code is sufficentily covered by a test (one I wrote just a
few days ago).
Change-Id: I8eb57e308bb2b281e0e72499b4d46f93a4dfa5f4
This patch fixes two styls issues I could not separate:
* Hook handler functions do not need to return true. This is the default
anyway, and meaningless.
* Counting is possibly expensive and not needed when all we need to know
is if an array is empty or not.
Change-Id: I460776c981638806a606d9bf88fc8579d6da8c0e
Also renames $action to $name in APIQueryExtracts.php, because trying to
document the parameter revealed that "action" doesn't match the use of
the parameter.
Bug: T170580
Change-Id: I1b7f3f0e17b118ea9bcfd28c69321aa692aad4e3
Changes:
- ApiBase::setWarning() is deprecated, use addWarning() instead
- ParserCache::singleton() is deprecated, use MediaWikiServices instead
- Exception import is not used, drop it
- added MediaWiki 1.29 as a requirement
Bug: T166714
Change-Id: Ib81e5acbb28e1f803c7a792b9f990f2aa6d57521
API Parse request fails from time to time which causes PHP notice
error. In order to understand whats going on lets introduce error
logging as temporary solution. This will give us possibility to
find the error instead of silently returning null. For now we will
keep old behaviour and return null in that case explictly. This will
avoid future php notice errors.
Changes:
- when API parse request fails log the error and return null
Bug: T169017
Change-Id: Ib908821b76a1e8b59235643854752c4f5910a274