Instead of conditionally adding it, move the check for the section being new or
not into the constraint, to reduce the logic needed in
EditPage::internalAttemptSave().
Bug: T157658
Change-Id: If16f5a097dd38c5206f748fa4fb8dc6e56cf09cb
Use the renamed ExistingSectionEditConstraint, and just make the content it
gets nullable.
Bug: T157658
Change-Id: I6e077f1e54ea05f77b431a7437c4a56c9dc56306
In preparation for also handling the AS_REVISION_WAS_DELETED failure in the
constraint, rename it in a separate commit so that git can more easily track
the change.
Bug: T157658
Change-Id: Id55b40d8e327429fbaf45a96c0b00caaa9110da1
Instead of conditionally adding the NewSectionMissingSubjectConstraint and
MissingCommentConstraint based on creating a new section, always add those and
have the constraints themselves just pass if not creating a new section
Bug: T157658
Change-Id: Ie5bf352bd714b6b706445f4f02c986706f26bb1f
getPermissionStatus() does the same thing but better.
A lot of things use the legacy error arrays though, we're nowhere near
removing it.
Change-Id: Iff60dbb0593329a584d003b2407bbf24d5b22aea
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I4ff4d0c10820dc2a3b8419b4115fadf81a76f7a2
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: Ib326ae1e5c8409a98398c721e8b8ce42c73bd012
Previously the edit rights check would fail if you didn't have edit
rights in general. This made it difficult to write custom permission
extensions that want to give users edit rights to a few specific pages
while not giving rights in general.
This check goes back to 2005 when the edit rights system was first
introduced a2a28a34c1. Presumably per-page permissions didn't exist
yet.
Bug: T342515
Change-Id: Ibcf0e18c44912abdd02a676a551da3cc7ed22ee0
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
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
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
