The 'editconflict' message is used by the normal edit form, and it
expects a parameter (page name), which was never passed.
'edit-conflict' should have been used instead.
This doesn't change the error code, which is mapped in ApiMessageTrait
and it already has a case for 'edit-conflict'/'editconflict'.
Change-Id: Ic95af27a67b95310b27ec344503d0a5cd88d79a2
Some of the errors are suppressed because they're phan false positives.
The idea behind this is that they'll be fixed in a future version of
phan, and we'll just have to remove the suppressions.
Note: I'm disabling UnusedPluginSuppression so that we can start suppressing
issues even if they're still disabled. The sniff should be re-enabled
as soon as we upgrade phan.
Bug: T231636
Change-Id: I0f7fa06a9e03fbb86c7a5eb6e50a850bb258a7f7
This reverts commit 01564dcbf7.
Reason for revert: I find the empty case far clearer as to intention than this change, and I doubt this is such a hot path that optimization should take precedence over clarity. If we really want to get rid of the empty case, I'd have structured it somewhat clearly as
if (
// always allow undo via api, T230702
!( $params['undo'] > 0 ) &&
// [something else here to explain this clause]
$contentHandler->supportsDirectApiEditing() === false
) {
But even that is IMO less clear. At the very least this seems to deserve more discussion.
Bug: T230702
Change-Id: Icc16250faad31abf7308c4af9be2e7658540346c
The code in EditPage and SpecialMovepage does this primarily in web UI
code paths that aren't called by the API. EditPage also has a check in
the internal code path used by the API, but ApiEditPage runs its own
permissions check first and won't reach that code path.
Bug: T216245
Change-Id: I6263c8b60a24f3195dba583463f1ce4b004f82f5
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
Bugs fixed:
* The major one was that appendtext and prependtext seemingly didn't
work at all on empty pages in the MediaWiki namespace, because
$this->getTitle() was being used in place of $titleObj.
* Negative undo/undoafter were not rejected in a correct fashion.
* If a logged-in user who was not allowed to upload images tried to
create an image redirect, the error message used a nonexistent key.
I also replaced assertEquals with assertSame.
I also removed a bit of clearly dead code. This includes a "break"
following dieStatus(). If we actually want this break so that nobody
adds a case after the default and then removes the dieStatus() so the
switch incorrectly falls through, it could be re-added with
@codeCoverageIgnore.
I put the fixes in the same commit as the test changes because I like to
keep fixes together with the tests for those fixes.
All code now shows up as covered locally, except for one line that seems
to be a PHPUnit bug.
Change-Id: I9375bc5f40268fd681a2d447c66a03f40b23390a
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
PHP 7.2 broke existing functionality in making count( null ) raise a
warning. So add tests for null all over the place, or change tests where
we know the value is null or an array (but not false, empty-string, or
0) to just cast to boolean.
Bug: T182004
Change-Id: Idfe23a07daa9f60eee72f2daf04304be87057a29
Get rid of the hack that turns unicode into hexadecimal codes for
browsers that don't support unicode, and prevent their edits entirely.
And instead of relying on $wgBrowserBlacklist, use a hidden HTML form
field - if the contents are mangled and don't match the original, then
reject the edit.
Bug: T67297
Change-Id: I20c2e396d7dfd6a3b23b94b218f94a847522576b
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
In cases where $result is non-null but doesn't have the 'spam' key,
constructing the fallback array was raising a PHP warning.
Thinking it over, we should just use a switch instead of making an array
of known fallback messages. It's longer source code, but probably less
real work than constructing an array where only one entry will actually
be used.
Bug: T153590
Change-Id: I50349c56692c4b2f9a8e560a849c36db1082120e
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
This may negatively affect performance and the whole purpose of the
hook (making it possible to reject an edit from an extension while
providing detailed error information in the API result) has been
invalidated by 09a5febb7b, which lets
EditFilterMergedContent do this too.
I think it was intentional that the hook was called with just the text
passed to action=edit API. Making it actually be called with the text
that's going to be saved would require more work (e.g. for
automatically resolved edit conflicts, T73947).
Very few extensions use this hook. I'm fixing AbuseFilter to use
EditFilterMergedContent in I30c1e3d0a6c10888e6ac53745313434474663cce,
we should also review ConfirmEdit, ProofreadPage and SpamBlacklist to
see what behavior they really expect.
This reverts commit be97167ab6.
Change-Id: I62713419496bcf57364a8fa9de93c0c8ddc3e91c
It might be even nicer to separate undo into action=undo,
but for now undo is done via ApiEditPage and should be
allowed for all content models.
Bug: T101694
Change-Id: I833bcc20d86fa5bf216dc9444e2b8a16ddd45f66
Some were being logged, and some weren't. Let's log them all
automatically when PARAM_DEPRECATED is processed, instead of requiring
each module to manually log them.
Bug: T117569
Change-Id: Ia38aeeccd0b9857b12b28914f509284483fbcca8
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
New types 'text' and 'password' for where a <textarea> or
<input type="password"> would be preferred over <input type="text">.
Some timestamp parameters get actually tagged as 'timestamp'.
'submodule' types change the 'submodules' output property from a boolean
to an object indicating the mapping from values to module paths. And
they get an indication of the submodule parameter prefix (e.g.
generator's "g"), if applicable. "generator" actually gets reported as a
submodule type, using this new mechanism.
action=paraminfo will now indicate ApiBase::PARAM_RANGE_ENFORCE status,
and return better-formatted defaults for timestamps and booleans.
Change-Id: Ic862d6f8fe13f7eb6b4298683514d33af5823e47
The Title object's cached content model isn't updated after the edit.
The Article object fetches the model from the revision that was just
created, so let's just use that instead.
Bug: T96937
Change-Id: I4c5ab3ec6829d403a29a8a8f55e7458730369034
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
This adds supportsDirectApiEditing and
supportsDirectEditing methods to ContentHandler. Both
return false by default for the ContentHandler base
class, and true for TextContentHandler and it's
derivatives. (everything in core)
Extension content types that directly extend
AbstractContent / ContentHandler, often / generally don't
support direct editing. EntityContent in Wikibase
and Flow boards are the two such content types currently
in gerrit-hosted extensions.
The use and direct settings of the allowNonTextContent
member variable is replaced by enableApiEditOverride and
a setter for that. The only place allowNonTextContent is
used in all of Wikimedia-hosted git repos is core itself
(EditPage and ApiEditPage), so should be safe to make
this change.
With this change, Wikibase can remove its ApiCheckCanExecute
hook handler that disallows editing there, and MobileFrontend
could check if direct editing is allowed before enabling it's
editing features, instead of Wikibase having to add
MobileFrontend hook handlers to disable the features.
Bug: T96382
Change-Id: I276cd6ecedf38108f1f2be16b38e699e8c5d2d0c
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
So that we can determine whether a save attempt succeeded or failed,
to log saveSuccess and saveFailure events from the server to Schema:Edit
on meta.
Bug: T88027
Change-Id: Ib861262603872e67600d1aab9bde3b58a8dd1738
