Old PHP versions are fine doing a `switch` with anything, even
if the types don't match. This changed. More recent PHP versions
start to bring up notices and such when a `switch` accidentially
compares e.g. an object with an int.
Bug: T255177
Bug: T258790
Change-Id: Ib415bd2fb394b95b02737b6df50e4e1fbbc440d3
Currently, if an extension aborts the save of an edit (e.g.
ConfirmEdit or AbuseFilter), they add a message to resubmit the form
(e.g. with the correct CAPTCHA or after reading an information
message). In this case, and in case that the user activated the
"Prompt me when entering a blank edit summary" option, MediaWiki will
ask to provide an edit summary or re-submit the form to save the edit
without a summary. After clicking submit again, an extension maybe
aborts the edit again (for the same reason as for the first time), and
the user need to re-submit the form again. After the submit, MediaWiki
will ask for the edit summary again. The user only sees this loop.
The cause is, that MediaWiki doesn't know, that the edit summary
warning was acknowledged by the user already. This commit changes how
the wpIgnoreBlankSummary hidden field is added to the form output. It
now is added, if the wpIgnoreBlankSummary form field was already set
in the request. This is only the case, if the user already clicked the
save button again (after seeing the edit notice).
Bug: T12729
Change-Id: I53a6cf277f77e033d4b75e64731fd37b46c3926e
When viewing Special:Contributions for a hidden user and
a missing user, or the user page of a hidden user and a
missing user, if the viewer cannot see hidden users
the output should be the same for hidden users and
missing users.
To that end
* In EditPage.php, for users that exist but are hidden from the
viewer, do show `userpage-userdoesnotexist` and do not show
an excerpt from the block log.
Bug: T120883
Change-Id: Ife272a0eb1f3322bc8eb30ca803bd21801acba3e
The conversion of text to a content object will be part of the
eventual backend, while the hook running won't be - flip
the order to make eventual migration easier
Bug: T157658
Change-Id: I9b3a8c5380b76b565be339ccf33537545150c352
The styles can be removed as there are no caching implications here
If a skin is loading `legacy` feature or providing its own (e.g
Minerva)
Non-Wikimedia skins loading content but not legacy will lose
styling here, but that will be consistent with other message
boxes in the interface.
Bug: T269797
Change-Id: I5cfa9d83bedd2786d65d835c1f7623b7a61317c4
Avoid modifying $editContent passed by reference,
in preparation for moving the method to the EditManager backend
Bug: T157658
Change-Id: I413c9896a9a3e57c3ffe11d071ff9bf2b57679f8
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
So that, once the method is moved to the EditManager, a
request context is no longer needed
Bug: T157658
Change-Id: I2076458dd92c7ea12dba9e7a4d75e60355a05e6a
Specifically, remove the conditional processing of
ContentModelChangeConstraint and ChangeTagsConstraint in
favor of early returns within the constraints
Bug: T157658
Change-Id: I377c0e3d9611d2da0a2d0f9bca055d65a1bec7e6
Add some to-do comments, reorganize some code, should be a no-op
Most notably:
- ::newSectionSummary() now returns an array instead of "returning"
the anchor for the new section by modifying a parameter passed by reference
Bug: T157658
Change-Id: I88bce764d04140653cc847185a823d79ff555bb5
Make private the methods only needed
in the class (and tests), no need for deprecation
because they are not used in any extension per
codesearch. Remove EditPage::setPreloadedContent
entirely, since it is unused.
Bug: T252907
Change-Id: Id47421e01da51d57842390682ace2c33eec3b467
Cleaner and simpler if the constraint takes care of determining
how to handle the section title
Bug: T157658
Change-Id: I45de1aca77fe1ddcd3d94b6ca964328d9911b440
If there is no revision, it is set to null, otherwise it is
the result of RevisionRecord::getContent, which is
either a Content object or null
Bug: T251023
Change-Id: I03255fc453e1d7437e5d701b098cddca21816fda
There is another place a missing summary is
checked, with different parameters and under
different conditions
Bug: T157658
Change-Id: I988a34a2a130244e6e250259b66727ef979a91ec
EditPage::runPostMergeFilters used to run two hooks,
EditFilterMerged and EditFilterMergedContent, and checked
for a hook error after each. When the EditFilterMergedContent
hook was removed in 99800a9e03,
the check for a hook error created as a result of running that
hook was not removed.
Additionally, the hook error is already checked elsewhere
before the method is called.
Bug: T157658
Change-Id: I6704906c2abda2602f9994121f7cbd7c8a059eea
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
Simplifies the use of constraints - only use a single
Runner.
Should be a net no-op in terms of whether an edit is
allowed or not, but the error code returned may change
if multiple constraints would have failed and a different
one is now checked first.
Bug: T157658
Change-Id: Ia8745eb06e96bd89e735fe64b2f9fdfcf5d0f917
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
Will make moving to constraints easier
Should be a net no-op, at most some failures
will result in different error messages based
on which check comes first
Bug: T157658
Change-Id: I1adb6e0f88c5c460a9cfdaff9a094da4e485953e
Rather than using wfDebug, retrieve a
dedicated logger, so that it can eventually
be injected
Additionally, normalize the messages
using context instead of concatenating
the variables.
Bug: T157658
Change-Id: Ie8f5d503e0e872e017b37f6849ead2abbd0e1176
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
