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
EditPage checks this using getBool(), not getCheck(), so empty string is
interpreted as false.
Also clean up a long-obsolete comment.
Bug: T87188
Change-Id: I18f376cefad44295874d7b1cd760ba6fc966be29
ConfirmEdit was tripling the amount of time it took to save a typical
page via the API, since it was assuming that the APIEditBeforeSave hook
was giving unmerged wikitext, requiring a full parse of the content
before and after the edit in order to check the addurl trigger.
Apparently nobody bothered to update it after Ia59fb6bb.
APIEditBeforeSave is unusable anyway, because it is given the serialized
content, without any information about the content model. It really
needs the Content object in order to do it properly. So instead, adapt
EditFilterMergedContent for the purpose. Incidentally, that avoids the
inelegant defined('MW_API') check in ConfirmEdit's
EditFilterMergedContent handler, since both API and normal edits are
handled by EditFilterMergedContent in the same way.
Unfortunately the interpretation of the 'value' member in the Status
object passed to EditFilterMergedContent is not extensible, being an
integer instead of an associative array. So we add a custom member in
order to get the result array back down the stack.
Another obstacle to this design was the lack of an EditPage object
passed to EditFilterMergedContent. ConfirmEdit was previously directly
calling EditPage::showEditForm() with a $formCallback which outputs the
necessary HTML. Instead, I hacked up runPostMergeFilters() a bit, to
allow the hook to request that the edit page be shown again even if
hookError is not set. Then a new EditPage::showEditForm:fields hook does
the necessary HTML output, instead of $formCallback.
Marked $formCallback as deprecated, since I think it is now unused.
Change-Id: I4b4270dd868a643512d4717927858b6ef0556d8a
Add the user right 'editcontentmodel', which is required to change the
content model while editing a Page.
Bug: 70901
Change-Id: I54f59539f1045092ec0de76c31cb47ca19c56874
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
This change enables the direct creation of empty pages without needing
to use a work-around (such as "{{subst:ns:0}}"). A warning is added as
the message "blankarticle" to request confirmation that the empty page
was meant to be blank. A automatic edit summary has been added when
creating a blank page. The message is: "autosumm-newblank."
The API has been updated to permit the creation of empty pages, when
"text" is null, but not non-existant.
Unit tests have also been added to test these features.
Bug: 57238
Bug: 65206
Change-Id: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
