When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
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
Use multiple error boxes instead of a wikitext list of error messages,
as the latter has several issues (as reported on phab). Also, remove the
edit-error-* messages as they don't seem to add any value. Also, don't
use the passed-in context, inject what the class actually needs instead
(but keep the context for the hook).
Bug: T303060
Bug: T230229
Change-Id: I2806e57826e7ab062b45dd1d9972b05fd6baeafb
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
This is the default anyway when using ->with(). The test code
becomes so much more readable without this, I would like to
argue. Let it just say "with these values".
Because of the way I split my changes into multiple patches
there are a few other changes in this patch I could not split,
e.g. removing unnecessary ->any(). This is the default anyway
and doesn't make the test more specific.
Change-Id: I34990799fa9258ba8dc64c7e78ec43f7903b7681
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
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
No longer need the factory for many of them
Bug: T271977
Bug: T157658
Follow-up: I12a2f71f52a1ba7e94bf325621e62ed0e255601b
Change-Id: I5019ea46bccb1f23643424c2798061a25eb3f623
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
A step towards a more common interface between the different
constraints, detect whether the content model changes within the
UserRateLimitConstraint rather than relying on EditPage to inject
the answer
Bug: T157658
Change-Id: Ifa35cbabe74df458784a10b3d2815a1e8e7dcdf8
Specifically, remove the conditional processing of
ContentModelChangeConstraint and ChangeTagsConstraint in
favor of early returns within the constraints
Bug: T157658
Change-Id: I377c0e3d9611d2da0a2d0f9bca055d65a1bec7e6
Cleaner and simpler if the constraint takes care of determining
how to handle the section title
Bug: T157658
Change-Id: I45de1aca77fe1ddcd3d94b6ca964328d9911b440
There is another place a missing summary is
checked, with different parameters and under
different conditions
Bug: T157658
Change-Id: I988a34a2a130244e6e250259b66727ef979a91ec
- 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
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
Factory is a service in ServiceWiring, given the number
of dependencies that will eventually be needed, but is
internal and has no corresponding method in MediaWikiServices
Bug: T157658
Change-Id: I801a09f5133bed14da10c64a42ca0658024357d3
This is the start of "Phase 1" of the migration described in
T157658#6191234. For now, only a single constraint, the
requirement that EditPage::$unicodeCheck match the expected
value, is moved to the new system, in the UnicodeConstraint class.
Both the EditConstraintRunner and the new UnicodeConstraint
have 100% test coverage with pure unit tests.
Bug: T157658
Change-Id: I4fc806ec0fd631e265948a59244295eebec691fa
