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
Also
* Fix a bug where action-reverts doesn't work for anons
since the userid is always 0 for them, instead use the username.
* Start adding block log flags consistently with core
Bug: T124789
Change-Id: Ic6680dad891e2169b392fcfefc1e313af85bc92f
Zopfli is the most efficient DEFLATE compression algorithm, trading run-time
performance for file sizes that are typically 3-8% smaller than those produced
by zlib with the maximum compression setting. Its output is Deflate-compatible,
so no specialized decoder is needed.
This change was created by running zopflipng against all the PNG files in this
repository. The exact invocation was:
git ls-files --exclude-per-directory=.gitignore -- '*.png' \|
parallel zopflipng -m -y {} {} \;
Files which zopflipng was not able to compress more efficiently were left unmodified.
Bug: T127608
Change-Id: Ib947620d9dd4d9e5760b2b7ab42f5bea1734e654
Zopfli is the most efficient DEFLATE compression algorithm, trading run-time
performance for file sizes that are typically 3-8% smaller than those produced
by zlib with the maximum compression setting. Its output is Deflate-compatible,
so no specialized decoder is needed.
This change was created by running zopflipng against all the PNG files in this
repository. The exact invocation was:
git ls-files --exclude-per-directory=.gitignore -- '*.png' \|
parallel zopflipng -m -y --iterations=1000 --filters=01234mepb {} {} \;
Files which zopflipng was not able to compress more efficiently were left unmodified.
Change-Id: I82b3141f3f19e594ab955f250e47dc6311e337c2
Task: T127608
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
