Changes after this conversion:
* order of the fields changed slightly from the original ( User,
Filter, Title ) to ( User, Title, Filter )
* $this->mSearchUser is set as the Default value of 'user'
field, making the value from the request show up there even if
its value was invalid. Earlier, it should show up 'null' due to
loadParameters() validation checks.
Bug: T132287
Change-Id: I614cd9b962b7b672e43dd35b14700c72f3425c1f
substr_count() is just as fast as looped strpos() when there are no
matches, and gets faster as the number of matches increases.
Note that this introduces a small change in behavior when the needle
is composed of repeated substrings, e.g. 'asdasdasd' or 'aa', and
haystack is such that the needle can be matched in overlapping
positions, e.g. 'asdasdasdasd' or 'aaaaa'. The old implementation
counted overlapping matches, the new one doesn't. I don't think this
behavior was intentional and I don't think this change will cause any
real problems.
Change-Id: Icc905ca34bf08d63e969787a5e3c119d498bf878
* Defer the slow profiling updates to post-send
* Convert to the object stash, so that all DCs see
the same values
Change-Id: I08316c6a3192bd69248cf5ab5a3ed8185341c313
It seems generally unnecessary, looks weird in translatewiki.net,
and is not translated to most languages.
Change-Id: If17cd4594b283cbadfda7dd0135cc5a5b2931f25
Previously, 'false & a == b' would actually execute the comparison and
count it against the condition limit, while 'false & (a == b)' wouldn't.
They behave the same now.
mShortCircuit was only checked for the most potentially expensive
operations (computing functions and getting variables), all the other
operations on bogus values generated by this would be executed and the
results ignored later.
This probably doesn't noticeably improve performance, but it corrects
how the condition limit is counted.
Bug: T43693
Change-Id: Id1d5f577b14b6ae6d987ded12689788eb7922474
With the new behavior, the number of conditions in incremented when:
* Evaluating a function
* Evaluating a comparison operator (== === != !== < > <= >= =)
* Evaluating a keyword (in like matches contains rlike irlike regex)
Previously, the number of conditions was incremented when:
* Evaluating a function
* Entering the comparison operator evaluation mode
This resulted in a number of surprising behaviors. In particular:
* '(((a == b)))' counted as 4 conditions, not 1
* 'contains_any(a, b, c)' counted as 5 conditions, not 1
* 'a == b == c' counted as 1 condition, not 2
* 'a in b + c in d + e in f' counted as 1 condition, not 3
* 'true' counted as 1 condition, not 0
It is still possible to easily cheat the count by rewriting comparisons
as arithmetic operations. I believe this is meant to advise users of
the complexity of their rules and not really enforce strict limits.
Bug: T132190
Change-Id: I897769db4c2ceac802e3ae5d6fa8e9c9926ef246
$params[0] is the full prefixed page title, with namespace.
$params[1] is whether the move was with or without a redirect.
Bug: T121963
Change-Id: I880bb227f2fc97394a68187e7b8391acf5aeaf5e
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
We were only recording the total number of conditions used by all filters,
then treating it as if it was the per-filter number, resulting in crazy
stupid values. We were also not clearing this when a filter was edited.
(This does not fix the remaining problems mentioned on the task.)
Bug: T53294
Change-Id: I4f9f88f94469b977fe60c554b76e94edacac3462
Follow-up to b60829a60c.
I'll fix up message translations on Translatewiki when this is merged.
Bug: T132189
Change-Id: I1ecaedd7489b264ed621309b6fbfb63b9287a437
This reverts commit afb78deb84.
I'll guard this behind a global and fix up the localisation messages
in a separate commit. This is a straight revert.
Bug: T132189
Change-Id: Iff4aa6d7d543db8f47c5f81f3c206dafcd5373dc
* 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
