Various pieces of the tagging system will break if the tag name contains
slashes or commas, so that should be checked for.
MediaWiki core (as of Ic5d75432) contains a method for doing just that,
so use it if possible.
Also require that tag names be either:
* Intended for reuse (canAddTagsAccompanyingChange)
* Already in use
* Creatable
This prevents the use of software-defined tags (unless whitelisted)
or tags that are blocked from creation (e.g. OAuth reserved tag
prefixes)
Add caching for tag lookup since it's used more often now.
Bug: T92956
Bug: T27151
Depends-On: Ic5d754323cbfd2c2b54c4df1245767946ebb1821
Change-Id: Ibc3095879f276a5436362f471b885e64f338522e
All usages of Linker::link() and Linker::linkKnown() has been replaced with LinkRenderer
Bug: T149346
Change-Id: Id087fe2aeaae81445e83e020ef66b541d9da4060
This adds the new_content_model and old_content_model variables. The
latter will be an empty string upon page creation when there is no old
revision.
This also required adjusting the null edit detection to not treat
content model changes as null, as well as some other internal
refactoring.
Bug: T145489
Change-Id: I7c3385056751421ba22efb7d8d064981420e8819
$content will always be a Content object, the only caller is the
EditFilterMergedContent hook, which always passes one.
Change-Id: Ic6356c51ec48084c27ce046b78d2380e723cd4b0
$wgUser causes issues when it is not properly set when doing deletions in jobs and we want to
generate variables for the deletion performer anyway. WikiPage::doDeleteArticleReal already
ensures that $wgUser is only used when the performer is not set. Also updated docs.
Bug: T138571
Change-Id: If4895fe86acfd1dc2c439837df3830f9b2214336
The error code 'abusefilter-disallowed' or 'abusefilter-warning' is
used, depending on whether the filter only warns (and will allow the
action when retried) or prevents the user from performing the action.
The API response has been extended with some additional properties.
* For simple filters with no custom messages where the only action is
'disallow' or 'warn', the error code is the same as before.
* For filters with different actions, different error codes would
previously be returned; 'abusefilter-disallowed' will be returned
for them all, with the actions taken listed in the
.abusefilter.actions property of the API response.
* For filters with custom messages, the message key would previously
be used as the error code; now 'abusefilter-disallowed' or
'abusefilter-warning' is used, with the message available in the
.message property of the API response.
Also cleaned up some dead "forwards-compatibility" code and made a
recently introduced public method private.
The new functionality depends on Ifac8995a4d16d11840cee814177fc2808bc2072c
in MediaWiki core, older MediaWiki versions behave mostly as before.
The new .message property contains both the key and the parameters
duplicated from .abusefilter, so that the client doesn't have to know
what AbuseFilter is - it'll be able to just display the given
message with the given parameters. My specific use case is the upload
dialog in core (core shouldn't have to know about any extensions).
See also TitleBlacklist change I97c1f5c6bbbdfc0b8ea9914bb075d5299c14df8f.
Bug: T137961
Change-Id: I5780eae96930211191ecd874aacf53fdacb58f89
This allows filters using `action='upload'` to use the variables
`summary`, `new_wikitext` and several others that previously were only
provided when editing pages (`action='edit'`).
This is achieved using the new UploadVerifyUpload hook, introduced in
MediaWiki core in change Ie68801b307de8456e1753ba54a29c34c8063bc36.
`action='upload'` is now only used when publishing an upload, and not
for uploads to stash. A new `action='stashupload'` is introduced,
which is used for all uploads, including uploads to stash. This
behaves like `action='upload'` used to, and only provides file
metadata variables.
Filter authors should use `action='stashupload'` when a file can be
checked based only on the file contents, and `action='upload'` only
when the wikitext edit needs to be examined too.
Bug: T87381
Bug: T89252
Bug: T139848
Change-Id: I9654f82ecda82e4917fd0ac6b364b947a1434c73
Edits should not wait on this to finish, especially since it does
both the minor and non-minor edit cases, only one of which actually
being useful. If the cache is there in time and there is no edit
summary it will be used; if not, there probably no reason to wait.
Bug: T138550
Change-Id: Ifc3b97ddf4dbb94f8ec3eacfcd5c8994c69aafbc
It was only needed for MediaWiki prior to 1.25
(09a5febb7b024c0b6585141bb05cba13a642f3eb).
We no longer support those versions after
d527574d2b.
Bug: T137832
Change-Id: I9d0b7e7713c805ebc7bf59f55456e69c6491e265
This should improve page save times when manual edit summaries are
not used (and in a few cases, where they are).
Also fix a few annoying IDEA errors with block comments.
Bug: T137698
Depends-On: I2e407a3ac8b74e77bf88b1e34c1519f4dea63b80
Change-Id: I972e9147a5e52a941f478eaf1e96dc3ef8bdfe94
Repeats I61e4327ef3c7a31b19feef727de7d683f69e260b (which had to be
reverted due to a problem with an ancestor patch) without any
significant change.
Bug: T110448
Bug: T135360
Change-Id: I1688cf9fbcb04bb56d075c9f0876bd0ffeced4f6
Rename $wgAbuseFilterAvailableActions / $wgAbuseFilterRestrictedActions
to $wgAbuseFilterActions / $wgAbuseFilterRestrictions and make
them an associative array instead of a plain one, as that works more
sanely with extension registration. (The renaming helps to give more
useful errors to sites using the old config.)
Change-Id: I790d39c2849922d7daf7479f298cd90cf30af129
Storing "false" is not allowed, so this resulted in duplicate fech log
warnings in that case.
Bug: T133728
Change-Id: I985700f8c42773569e53b54820b972e50be776ba
Back when APIEditBeforeSave was being introduced here, it was
impossible to return error data for API requests from it (T34216). But
this hook runs a lot earlier than EditFilterMergedContent, and only
gives us the text submitted in the action=edit API call and not the
actual text that's going to be saved, which are different for section
edits (T54077) or edits where an edit conflict is automatically
resolved (T73947).
T54077 was solved by making the APIEditBeforeSave lie that there are
no sections edits in the API. Perhaps T73947 could also be resolved by
lying that there are no edit conflicts in the API, but it seemed that
this would require duplicating even more logic from EditPage in the
API than T54077.
And luckily, EditFilterMergedContent recently gained the ability to
return precise error messages to the API (in MediaWiki 1.25,
I4b4270dd868a643512d4717927858b6ef0556d8a). So let's use that if
available and only fall back to APIEditBeforeSave on older versions.
Bug: T73947
Change-Id: I30c1e3d0a6c10888e6ac53745313434474663cce
* file_mime
The MIME type of the file, e.g. 'image/png'.
* file_mediatype
The media type of the file, one of 'UNKNOWN', 'BITMAP', 'DRAWING',
'AUDIO', 'VIDEO', 'MULTIMEDIA', 'OFFICE', 'TEXT', 'EXECUTABLE', 'ARCHIVE'.
* file_width
Width of the image in pixels, or 0 if it's inapplicable (e.g. for
audio files).
* file_height
Height of the image in pixels, or 0 if it's inapplicable (e.g. for
audio files).
* file_bits_per_channel
Bits per color channel of the image, or 0 if it's inapplicable (e.g.
for audio files). The most common value is 8.
Bug: T131643
Change-Id: Id355515a18d3674393332c0f4094e34f9f522623
At this point $wgUser->getId() will be 0 anyway because the $wgUser is
in the process of being created, so skip the call.
Bug: T124367
Change-Id: I4c6c999f1799db6ff21db3d9df537da643442d27
This query takes a large chunk of page save time (per xenon).
Try to perform the query before page save.
Bug: T116557
Change-Id: I50432658d387b24e47db7ed66880e53c3e4adee7
