Using MWProps will not raise an 'undefined index' notice and, if the
bitsdepth cannot be established, will return 0. This is way better than
returning the empty string or null, which cannot be treated as integers.
Bug: T218874
Change-Id: I2b585f3a2f257783c15f0fcdd2851f1e1ce4256b
Follow-up of I982d67aa62a899916a26452aceb9646df8c31232. The help text
was meant to be localized, and I probably forgot to do so in the
mentioned patch.
Change-Id: If394b02819911f9c97519b5c972977c38e6d83fa
The uppercase is just a leftover from a long time ago. Currently,
variables are case-insensitive, and we already perform a strtolower when
saving them. Since most parts of the code already use lowercase, the
uppercase leftovers only make it harder to grep the code to find
variables. As a bonus, make Ace recognize variables in a
case-insensitive fashion.
Change-Id: I72933fcc9952fc1aabf6464b2fc0b04ec39c024b
This patch adds missing methods for testing a filter against uploads in
RC. Please note that (as discussed below) using wfFindFile could be
relatively expensive (as it will be executed for 0-100 RC rows).
If this is true, then we should either use another method (but I
couldn't find a suitable one), or simply reduce the amount of testable
uploads to a reasonable limit.
Bug: T170249
Change-Id: Id406d4e1571873f49bb11e69029311b24ececf49
As escaping is handled by makeExternalLink itself. This currently makes
seccheck fail for any patch and is a merge blocker.
Change-Id: I2d21632bbc59abd4ea48aebdb6572d53f8fc89cd
So that they're easier to read, and because readonly is semantically
more appropriate.
Bug: T217143
Change-Id: I76be8e7fb1cf46efd0c03cde74344be6cb2a0902
Where prevents is used as a setter, use the new setter methods;
where it is used to determine whether a block blocks the target
from editing their talk page, use appliesToUsertalk.
Block::prevents was deprecated and replaced by several other
methods in I0e131696419211.
Bug: T211578
Change-Id: I166cc6f64c0f895ff8c631d2655c1c3208131371
Following up I636b4e56f39282593c737ace1d6ff2d90900d997, enforce a basic
clientside validation and don't fill the field with the URL parameter if
it's not valid.
Change-Id: If4fd015dff64237375a0c4d3b9fbcefbd54dba3e
Using break could halt parsing between operations, instead use continue
to parse all operations.
Bug: T214642
Change-Id: If67ddaffef280c2448c55ae536013758617bba68
For wgLang, there's a Language object available in the proximity, so just pass it.
For wgContLang, use MediaWikiServices.
Change-Id: Ic492007f2d5eeb8048d0919a4b9b7dd98c15c350
The following sniffs are failing and were disabled:
* MediaWiki.Usage.DeprecatedGlobalVariables.Deprecated$wgContLang
Change-Id: Ic167fc5e836c5437edc6b330e5d73f9913bc2859
In both SpecialAbuseLog and ApiQueryAbuseLog, we use
Title::getUserPermissionsErrors to check if the user is allowed to
perform 'abusefilter-log' on the API page... However, this is a
completely redundant check (which is also pretty expensive and queries
the master): for the SpecialPage, we can specify the required right in
the constructor and use checkPermissions, and for the API we can simply use checkUserRightsAny.
If I'm not mistaken, there's no benefit in using
getUserPermissionsErrors.
Change-Id: I4c4dbace67b24cc1f45e50ab1c0d251522935513
We do not validate the param, and instead only check if it was
specified. In the specific case of ViewHistory, specifying as "filter"
something invalid for a title (e.g. with a + inside) will throw an
exception, seen in production.
Change-Id: I636b4e56f39282593c737ace1d6ff2d90900d997
The case default was recently added, but didn't take into account that
"false" is valid too. Noticed by chance just before the train rolled
out.
Change-Id: I67ca475fa16ea449820f8c735531c2cc1b0ec975
Several people have reported throttle groups being hard to use, mostly
because the field doesn't have options with the usable groups. This is
because users can combine valid groups in many ways, and thus we don't
provide options. However, let's add an help link pointing to mw.org.
Change-Id: I982d67aa62a899916a26452aceb9646df8c31232
Now that Parser errors are on logstash, I noticed a huge spike of errors
on Wikimedia Commons, about 35000 per hour. They seem to be due to 2
broken filters, but id doesn't say which ones.
Change-Id: I8510319c075520f9a893cd7d56f2e30679e249ba
Tagging doesn't work for account creations, and probably never did. This
is because we used a wrong identifier for such actions. This patch fixes
the problem, although in the long term we should find a smarter way to
apply tags.
Also, clean AbuseFilter::$tagsToSet if the action will be prevented.
Depends-On: Ia8e38ba25d1989fe71714d2b76891c4587921466
Change-Id: I8edcca17ecdcf71397cc9b0d101e8b13ac112047
This may solve several issues, see T176291#4105438 for further details.
Bug: T191430
Bug: T176291
Depends-On: Iebbdeac7898b35beea79aa3d0cdf9d0fb265d726
Change-Id: Ia8e38ba25d1989fe71714d2b76891c4587921466
When updating the abuse_filter_history table, the sequence to use is the
one on afh_id... And we were using the af_id one since 2009.
Change-Id: I3e291c780119d74be5f47e745a8de13bda85486b
