The hhvm redis client returns false instead of null. This caused
JobQueueRedis to get stuck in an infinite loop. This works around the
difference by catching null as a signal for no more jobs.
It can be reverted when https://github.com/facebook/hhvm/pull/3127/ is
in all versions of hhvm we expect to run MediaWiki.
Bug: 67622
Change-Id: I9bbad42f36a80635097b8e0140b48b6492b2f0f5
Previously, only the global was unstubbed when StubObject::unstub() was
called. Now, the object given as a parameter will also be unstubbed.
(What about other references to the object, though?)
Change-Id: I431ddd61e24686fc2f014c30064808ce57fe1706
It is the only element in the form which has this attribute set,
so the tab order was not correct.
Bug: 67271
Change-Id: Ifa8fb91f9bf7a60e727ec7376d2bc3a851007634
While generator support was added to various actions, the continuation
parameters from the generators weren't being returned to the client.
This patch refactors the code for handling continuation out of ApiQuery
and into ApiResult, and then uses it in the other actions that need it.
Bug: 60734
Change-Id: I1a6e51cdc964ddcdd69aaa2f735223371233e8af
This icon comes from the crystal icon set (like all the other
icons here). They are licensed LGPL. See the COPYING file
in the skins/common/images/icons directory.
It was downloaded from
https://upload.wikimedia.org/wikipedia/commons/4/4f/Xcf.png
This goes along with change I127bcb5458, which caused the icon
to be shown for indexed xcf files.
Change-Id: I72aa00c4e605ff67f62f855c1475a07433fd4567
Adding mol, sdf, rxn, rd and rg file types to mime.types and mime.info
map to make them known to MediaWiki by default.
PHP's own module fileinfo module is not capable detecting Chemical
table files. Instead, they are reported as text/plain.
MediaHandlers can be attached by MIME type only. That's why these
changes are required for [[Extension:MolHandler]] to work.
Change-Id: I017507e4a950b3ce4e6576d12217cd42a337bad6
json, csv, and tsv are often detected as text/plain. However that's
not right. This patch causes MediaWiki to look at the file extension
of files detected as text/plain, and if the file extension is
for a "textual" type, use the mime type associated with that extension.
This change also changes the "does mime type match uploaded file
extension" check to use the mime based on the file contents
plus extension, as opposed to just the file contents. Various
documentation suggests this is more appropriate (e.g. line 807
of MimeMagic.php). In my opinion we should use just the file
contents when verifying file is not on blacklist, but use ext
when verifying file type matches extension, and for decided
what handler specific checks to run. Not the detect mime type
with extension doesn't override the detected mime type with
the extension, but only uses the extension if content based
detection is ambigious or not specific enough.
This patch should be reviewed by csteipp before merge for
any potential security implications.
Note: This is partially fixing a regression from 3846d10487,
where previously csv and json files were allowed to be uploaded,
and that change prevented them
Bug: 66036
Bug: 45424
Change-Id: Ib637fe6850a81b26f84dc8c00ab4772f3d3a1f34
