Currently, there are 3 block messages: sitewide, partial with restrictions, and
non-editing partial blocks. This will add namespace restrictions to the
partial editing blocks message type.
Bug: T204985
Change-Id: Ic17d5459e67c267fdee1fb2513d67428148ac85d
$logId holds the log entry ID of some specific log and the datatype
is an integer (int) which is correct but looking at the constructor,
it does take a bool (false) which contradicts the docs above. So per
@Thiemo's advice after review of prev PS, it would be better to replace
false with 0 and leave the docs untouched.
Change-Id: Ieceb79a6cbaa248e1b7a7d3c1d51eb26bb3a2d84
I'm intentionally only touching these protected properties and nothing
else, because I believe these are uncontroversial. They should be protected
according to modern SOLID standards, and actually are declared as
protected in the base class. What this patch effectively does is documenting
this fact, but it does not change anything.
Change-Id: I625307b58bd419c4a72e9842b2b46c08ed9b4f8e
It is an invalid value that should be (by spec) ignored by the
browser, but apparently some browsers don't ignore it, and when they
submit it back, it is converted to -0001-11-30 by our date parsing.
Bug: T209490
Change-Id: I2643767a0091c1c9db78706358903e1dc97b59d1
Block information needs to be more detailed if a block is not
sitewide. With this change, page restrictions will be visible
as part of the block information in Special:Contributions,
Special:Block, and Special:Log and via API
Bug: T197108
Change-Id: I5d2ef606f709bdd60bf52e2a048890b0f6360fca
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
When the date is specified using &year=...&month=... URL parameters
rather than &wpdate=..., HTMLForm can't automatically fill it in,
but we can explicitly specify the default.
Bug: T199856
Change-Id: I71f4953d57a3893190778e5bd763db108dc433d3
Also, the $default value in LogEventsList#getFiltersDesc was not
being generated properly and would have always been an empty array.
Bug: T199856
Change-Id: Id286c76259406521f12cda67a4a715032e022637
Now that all our supported PHP versions have array_filter()
with a third parameter, these functions aren't needed anymore.
Depends-On: I3b097a1a048baabcaca15dc214a3a1bb06e746cc
Depends-On: I0187e27ac47cbab099249572201d1a649226a734
Change-Id: I7cabd0252691a083cb749cf9d3a7a23f1d076c39
HTMLForm gets the input value from the request. The values
specified in the form descriptor were never used. (You can specify a
default value, but that uses the 'default' key anyway.)
Change-Id: I27934e1118492371e547dd5e94feb172a0510cc9
I missed this during conversion.
Follows-up on Iba3c6aa5ac40dcdee0792c2d045b238b02d76521.
Bug: T199856
Change-Id: If3f228425b217c9ccdb7d32e0bc899647797ed70
* All Xml generation code has been removed.
* The LogEventsListGetExtraInputs hook now needs a form
descriptor array and not plain HTML.
See I37e0d3e81a46239750465b9299279fbbd7c7f87a.
* LogPager and LogEventList also take the $day parameter
for 'From date (and earlier)' and pass it to getDateCond
as well.
* Since FormOptions can't automatically extract the date
from the request this is being done manually in the
execute method of Special:Log using MWTimestamp.
Bug: T117737
Change-Id: Iba3c6aa5ac40dcdee0792c2d045b238b02d76521
Whether or not LogFormatter::getActionText() and friends are safe
for html depends on the runtime value of LogFormatter::$plaintext
which is beyond the abilities of phan-taint-check's static analysis
to determine. Thus this method results in a lot of false positives.
To prevent that, add an annotation that marks the method as always
safe for html. This is not ideal, but refactoring this method while
maintaining back-compat looks like it would be very challenging.
Bug: T197002
Change-Id: I9aded350ed4acc733b4fb697dd3400686a178fa9
The number provided by the query can be arbitrary, so let's narrow the
input validation to booleans.
Bug: T194616
Change-Id: If03e6e2d5bbcf4f2d85047cc23ee5388b39fe114
Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
