We renamed many classes to be namespaced, but the `@covers` and
`@coversDefaultClass` annotations weren't updated properly.
PHPUnit didn't support short cover annotations with `use` statements,
these didn't trigger any errors yet, because they are class alias.
This patch is populated by a modified version of PhpunitAnnotationsSniff.
Change-Id: I6c602290a30099239b17d2dc0d67b1488b4eaeeb
The db/ directory does not have an owner and it's a mess in general.
These classes don't depend on anything in core except the rdbms library.
Let's simply move it there. In other words, Krinkle made me do it.
Since the class was moved in I6202e52ba73 merged less than a week ago,
no need to alias anything.
Bug: T321882
Change-Id: I24ceeb8bf765a50f441270136acd612359d50aa2
They are not suitable to go to rdbms library as they depend on mediawiki
pieces, the second best place is the db/ directory.
Bug: T321882
Change-Id: I6202e52ba7306d74261206c2ba7930c5f1a0a18e
* Illegal string offset and invalid argument supplied to foreach, due to incorrect type information
* Array internal pointer reset is unnecessary
* $hookData unused since MW 1.35 due to incomplete revert
* array_push() with single element
* Unnecessary sprintf()
* for loop can be replaced with str_repeat()
* preg_replace() can be replaced with rtrim()
* array_values() call is redundant
* Unnecessary cast to string
* Unnecessary ternary. Often the result relies on short-circuit evaluation, but I find it more readable nonetheless.
Change-Id: I4c45bdb59b51b243fa96286bec8b58deb097d707
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
Also moving TemplatesOnThisPageFormatter to the same namesapce as it's
only used by EditPage
Bug: T321882
Change-Id: Ibefc44eb64aedb430148b109090584c3e35794ab
Previously, `$this->summary` was used for two different purposes.
Usually it was just the summary. But when `$this->section` was 'new',
then it was actually the section title most of the time – unless
`$this->sectiontitle` was also set (in which case it took priority),
and until it was replaced by the real edit summary (near the end of
the processing, after copying the section title to the page content
and before saving changes).
Unsurprisingly some of the code didn't handle this duality correctly,
causing T191722 and T311533.
Now `$this->summary` is always the summary, and when `$this->section`
is 'new', then `$this->sectiontitle` is always the new section title.
The only place where this duality remains is in the input attributes
and query parameters, where 'wpSummary' is still used for both the
summary and the section title inputs (only one of them can appear,
depending on whether `$this->section` is 'new'). It would be an
unreasonable backwards-compatibility break to change this, and the
code handling this is somewhat isolated from the rest of the logic.
Bug: T191722
Bug: T311533
Change-Id: I5313ca9a045d112ece390b011a34192220e2abc1
The files in `tests/phpunit/includes/` directory are now all
covered. Will do sub-directories of `/includes/` next.
Change-Id: I8d5655ce267b6d32cf3c7ee40dc5d2992631b5a6
ContentHandler::getContentText() is deprecated and should be
replaced with Content::getText() for TextContent instances.
Change-Id: I556d3d3f64fafd1d54c4a0c5021efaff2d9c3ce8
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
When hook handler return false and use $status->fatal() to put up a error,
we should set $status->value to self::AS_HOOK_ERROR_EXPECTED to show edit form
and display error message.
Bug: T273354
Change-Id: I02d643c5cb1978da8ab749856493d75137b6cb02
There is another place a missing summary is
checked, with different parameters and under
different conditions
Bug: T157658
Change-Id: I988a34a2a130244e6e250259b66727ef979a91ec
Add
- ContentModelChangeConstraint
- EditRightConstraint
- ImageRedirectConstraint
- ReadOnlyConstraint
- UserBlockConstraint
- UserRateLimitConstraint
Additionally:
- Split EditPageTest into a separate file for
all of the constraints being tested
- Add a helper EditConstraintTestTrait
- Add debug logging for EditConstraintRunner for
the result of each constraint
- Changed the order of some of the checks, which
may result in a different failure code if multiple
checks were going to fail, but shouldn't change the
overall result of whether an edit fails or not.
Bug: T157658
Change-Id: Ib8f8b62b9928544e5559c96d82bf850dd8cf9b05
