| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I assume these are all either auto-generated by an IDE or the
language-level type declarations have been added later. In any case
the comments don't add any new information to what the code already
says. This is just extra clutter that makes the code harder to read,
I would argue.
There are many, many more comments like this. In this patch I
intentionally focus on the most trivial 1-line comments.
Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
|
| |
|
|
|
|
| |
This change improves type safety and code readability.
Change-Id: I839bff97e10188af79d658b44caa5413f6c538ad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is moderately messy.
Process was principally:
* xargs rg --files-with-matches '^use Title;' | grep 'php$' | \
xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1'
* rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \
xargs rg --files-with-matches 'Title\b' | \
xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1'
* composer fix
Then manual fix-ups for a few files that don't have any use statements.
Bug: T166010
Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a
Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
'summary' must only be used as the section title when 'sectiontitle'
is not provided. Otherwise the provided section title must be used,
even if it is empty.
Bug: T54747
Change-Id: Id86d5cdd9e04cf1b2f3fbf243a4b250e2924cf87
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
composer:
* mediawiki/mediawiki-codesniffer: 36.0.0 → 37.0.0
The following sniffs now pass and were enabled:
* Generic.ControlStructures.InlineControlStructure
* MediaWiki.PHPUnit.AssertCount.NotUsed
npm:
* svgo: 2.3.0 → 2.3.1
* https://npmjs.com/advisories/1754 (CVE-2021-33587)
Change-Id: I2a9bbee2fecbf7259876d335f565ece4b3622426
|
| |
|
|
|
|
|
|
| |
Cleaner and simpler if the constraint takes care of determining
how to handle the section title
Bug: T157658
Change-Id: I45de1aca77fe1ddcd3d94b6ca964328d9911b440
|
| |
|
|
|
|
|
|
|
|
| |
- EditConstraintRunner debug logging uses `info` for the failed constraint
- Differentiate between the two PageSizeConstraints in debug logs
- Add or tweak some comments
- Normalize SpamRegexConstraint logs
Bug: T157658
Change-Id: I9d0e8d48a104320f29831357b45a4003942b04fd
|
|
|
Bug: T157658
Change-Id: I06ef5796f9da7b0e8555768ec6fd128b4f778294
|
