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
We started to call Authority argument $performer everywhere,
and $performer->getPerformer() doesn't look that good.
Change-Id: Id2cf3f27b18340314e4ed1ea9931ad9404b4df6f
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
Interface is @internal and is implemented by EditPage; will be used in
the future when the backend is split and common status values are needed
for the different classes.
Doing separately to avoid cluttering the main work - just moves the
constant definitions. Since EditPage implements the new interface, any
existing EditPage::AS_* references will continue to work.
Bug: T20654
Change-Id: I71dafec2579b4a42dd08f3fc7e569e28c14d8753
For checks against `$wgSpamRegex` and `$wgSummarySpamRegex`.
EditPage methods will be deprecated in a separate follow-up patch,
as well as making use of the service where needed.
Bug: T251015
Change-Id: I12120b51073c31680713204cfeb5c61c0ca8c52c
Add `aria-label` attribute with explanatory description as value to the
`wpTextbox1` to allow screen reader read the purpose of the textbox for
visually impaired contributors.
Bug: T245863
Bug: T252355
Depends-On: I0628486e2201975464a77a55053a8d74ddfc57fb
Change-Id: Ib6fe49ade878757594fd28dac2bfd0ef8a7a5e8f
Luckily this was not really broken. The old and the new code do the
exact same. The old code was just side-stepping the documented way
this method should be used.
Change-Id: I3f25ba159df5dbfc67eb7ade3fe29a017e601162
A deprecation warning will be triggered if the constructor is called without providing a ContentHandlerFactory
Bug: T235165
Depends-On: I5996f0f01e28edf50d3caf2ca4557d64271d8545
Change-Id: Ie552b33a5644fa2aefd826df8fd18184434677b7
Added:
- ContentHandlerFactory
Tests:
- PHPUnit
Changed
- Calls of changed and deprecated
- DI for some service/api
Deprecated:
- ContentHandler::* then similar to ContentHandlerFactory
- ContentHandler::getForTitle
- ContentHandler::$handlers
Bug: T235165
Change-Id: I59246938c7ad7b3e70e46c9e698708ef9bc672c6
The method is not used anywhere:
https://codesearch.wmflabs.org/search/?q=toEditContent&i=1
There is another method with the same name in the EditPage class. But
this is unrelated. As far as I can see the method I'm touching in this
patch was copied from the EditPage class.
Change-Id: I51d167723bd70220adbf4ac36f15f3290b7eb653
This was originally a global search and replace. I manually checked all
replacements and reverted them if (due to the lack of type hints) either
null (that would be 0 when counted) or a Countable object can end in the
variable or property in question.
Now this patch only touches places where I'm sure nothing can break.
For the sanity of the honorable reviewers this patch is exclusively touching
negated counts. You should not find a single `!== []` in this patch, that
would be a mistake.
Change-Id: I5eafd4d8fccdb53a668be8e6f25a566f9c3a0a95
This is only called at one place in core and used in the TwoColConf
extention. The passed argument is always an array.
Change-Id: I4ca94442b79dc8871ed72943be733d100e093e44
Factored out some minor parts about building editor CSS classes.
getEditConflictMainTextBox() mainly mirrors showTextbox1 parts not
included were moved to the EditPage.
Change-Id: I671e095acc08382dd0a1c3d167fdaaa623ec5499
This is similar to the tracking of the occourance of
edit conflicts but tracks the resolution of the conflicts.
Bug: T182011
Change-Id: I9a0c05dc921946fb6e0580b56b663783ca0b1b6e
Extensions with custom content models (e.g. ProofreadPage) will extend
EditPage to provide a customized editing experience. However when
another extension like TwoColConflict wants to change just how edit
conflicts look, this causes problems since only one class can take the
place of EditPage.
So instead, split most of the frontend code for edit conflicts into
TextConflictHelper, and call it from edit page. Extensions can override
with the instance created by calling
EditPage::setEditConflictHelperFactory().
And to make that split possible also move EditPage::addNewLineAtEnd()
and ::buildTextboxAttribs() into a separate TextboxBuilder class that
both EditPage and TextConflictHelper can use.
Bug: T176393
Change-Id: Ie415edd84329c02d5762477f8a171fced85b01a2
