-----BEGIN PGP SIGNED MESSAGE-----
MediaWiki-CodeSniffer 24.0.0 is now available for use in your
MediaWiki extensions and other projects. This release features new
sniffs, an upstream update, and other bug fixes.
The 19.x branch for PHP 5.5 codebases also saw another release,
19.2.0, which just disabled the problematic
Here's the changelog for 24.0.0:
* Whitelist @after and @before phpunit annotations (Umherirrender)
* Update PHP_CodeSniffer to 3.4.0 (Kunal Mehta)
* Enable new Generic.VersionControl.GitMergeConflict sniff (Kunal Mehta)
* Copyedit comments (Max Semenik)
* Exclude methods in anonymous classes from the nested_functions sniff
* Disallow use of @access (Umherirrender)
* Add $wgLang and $wgOut to ExtendClassUsageSniff (Umherirrender)
* Enable Generic.WhiteSpace.IncrementDecrementSpacing (Umherirrender)
* Enable Generic.Formatting.SpaceAfterNot with spacing 0 (Umherirrender)
* Require mbstring since it is needed for FunctionAnnotationsSniff
(Mark A. Hershberger)
* Enable Generic.CodeAnalysis.EmptyPHPStatement (Umherirrender)
* Fix UnusedUseStatementSniff to find more unused statements
* Remove ForLoopWithTestFunctionCall (Tim Starling)
* Add a sniff to replace !! with a cast to boolean (mainframe98)
* Adjust warning text for PhpunitAnnotations.NotClassTrait sniff
* Expand ExtendClassUsageSniff to check for config globals (Umherirrende
* Also exclude anonymous classes in AssignmentInReturnSniff (mainframe98
* Replace sniff for forbidden globals by deprecated globals
Special shout out to mainframe98 as our newest contributor!
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
A few months ago I switched our TimedMediaHandler's config to support the
newer, more bandwidth-efficient VP9/Opus variant of WebM and to use these
preferably over the older VP8/Vorbis version when creating scaled,
(This does not affect upload support -- you may continue to upload video
files in WebM VP9, WebM VP8, or Ogg Theora formats, with either Vorbis or
Conversions of existing files on Commons ran in the background for some
weeks, finishing in November. I'm now running a final pass for
high-resolution files and any files on other wikis that didn't get a
conversion yet, in preparation for removing the VP8 derivatives in the next
couple of weeks to free storage space.
This should have relatively little visible effect for users, unless someone
is relying on the particular derivative files with extensions like
".360p.webm"; the new versions are named like ".360p.vp9.webm".
Note that IE 11 users using the "WebM Media Foundation Components for IE
<https://www.webmproject.org/ie/>" will not be able to play back the new
VP9/Opus files natively, as this driver has never been updated for VP9 or
playback instead. If you find this is troublesome, the recommended solution
is to switch to any other browser.
Third-party MediaWiki + TimedMediaHandler users should be aware that the
defaults are changing, and in future the VP8-specific support and code
paths may be removed. TimedMediaHandler will probably change a lot in the
coming months with upcoming WebVTT subtitle format, a streamlined
videojs-based player, and hopefully more!
At the Extension:Scribunto/Lua reference manual, at several places,
it is pointed out that the lua-libs should use the form 'mw.ext.NAME'.
This creates visual noise in the code. Any lib included should have a
extension page, thus it has already been given an unique name. In
addition, only the libraries that need to be preloaded are added to
the mw-structure, and those are the extensions. The ext-addition is
like saying "this is an extension and it is only extensions that needs
to be added to the mw-struct so we make it abundantly clear that this
is an extension".
The only cases where a name can collide is if some external lib is
included, that external lib has the same name as an extension, and if
someone in addition preloads the external lib. The chance is quite
frankly pretty slim, as there are rather few external libs that makes
sense to preload in this environment, especially as preloading imply
some kind of interaction with the environment. That means it is an
I guess I'm stepping on some toes here…
So to make it abundantly clear, not 'mw.ext.NAME' (or 'mw.ext.NaMe',
or 'mw.ext.name') but 'mw.name' (lowercase, not camelcase). If the
call is a constructor or some kind of builder interface, then
'mw.name(…)' is totally valid. I do not believe it is wise to turn the
lib into an instance by the call, but it can return an instance, it
can cache previously returned instances, and it can somehow install
the instance(s) in the current environment.
An extension should have any pure root libs at 'pure/name.lua' and
additional libs at 'pure/name/additional.lua', where 'pure' is
resolved in the 'ScribuntoExternalLibraries' hook.
what about abuse by administrators and stewards ?
From: Moriel Schottlender
Sent: Monday, January 7, 2019 7:53 PM
To: Wikimedia developers ; Wikitech-ambassadors(a)lists.wikimedia.org
Subject: [Wikitech-l] Changes to the Block
you written code that deals with or depends on user blocks? Read on.
The new “Partial Blocks” feature has fundamentally changed the
considers what “block” means; any code that handles blocks
whether the questions it is asking are still valid or should
expectations. Please read for more details.
A couple of months ago, as part of the Anti Harassment Tools
continued work on improving the general experience of our users
providing more robust tools to administrators, an RFC to enable
Blocks” has passed and has been implemented in MediaWiki,
way blocking users operates.
While the actual feature,
enabling the blocking of users for specific pages
and namespaces, will be
slowly rolled out as part of our rollout and
testing plans, the change has
resulted in a complete change of paradigm for
what “block” means throughout
= Change of paradigm =
Until recently, Block was fairly
straight forward; whether a block was done
on an IP range or a specific user,
the question the code would ask is “is
the user blocked from this action” and
the answer will be a boolean yes or
no, depending on whether the user was
blocked from the wiki and whether the
action was a blockable
With the new Partial Blocks feature, that question is now more
We are giving admins and wikis in general much more robust options
deciding to block IPs or users. “Sitewide” block is no longer the
option. Now, a user can be blocked from editing a specific page, and
from a specific namespace. There are also blocks that prevent a
action, such as uploading files or creating new pages.
means that the question “is the user blocked” is no longer accurate.
cases, the question should be “is the user blocked from the action
page”, because users may receive a block that is not sitewide, but
specific page or set of pages.
= What we worked on =
Harassment Tools team has been working diligently on making sure
that the new
blocking behavior does not produce obvious regressions in
does not add to any still existing inconsistencies. In
cases where we
identified a clear mismatch, we’ve tried to either fix it
outright or alert
the code owners to adjust.
If we have missed any iteration or use-case,
please open a Phabricator
ticket and add the ‘anti-harassment’ tag to it.
If the use-case is
sensitive or identifies a current loop-hole in the way
blocks work, please
make it a security ticket and alert us and the relevant
= General steps forward =
While the team is
following up on making the code clear and robust and
fixing what we’ve
identified as paradigm-changes to deal with, there are
still many instances
where the changes required to the code are not
straight-forward or clear.
Some extensions ask whether a user is blocked
and may need to change the way
that the product’s “business logic” behaves.
These are cases where we
cannot make the decision for the codebase. We
encourage you to look at your
product and consider adjusting if necessary.
= General guidance
We’ve identified some areas that may help code owners adjust their
to properly take advantage of the new feature and adjust to the
paradigm change. This list is not exhaustive, but may help you spot
in your code that can easily be changed:
* User::isBlocked() has
changed its meaning, and its use cases should be
re-examined depending on
what your code intends to check.
For the most part, if there’s a Title object
User::isBlockedFrom() is a good option. Otherwise, consider
User::getBlock() and Block::isSitewide()
* Block::prevents( ‘edit’ )
is an operation that doesn’t make sense
anymore, because a block on the
‘edit’ action now depends on context (the
* Determining whether a
block prevents a user from editing their own user
talk page has
For a sitewide block, if the $wgBlockAllowsUTEdit config is false,
block prevents the user editing their user talk page, but if it is
then whether they can edit their user talk page depends on
ipb_allow_usertalk flag on the block. For a partial block to a page
pages, these flags are not taken into account: if the user’s talk page
specified as a blocked page, then they cannot edit their user talk page;
it is not, then they can edit it. Block::prevents( ‘editownuserpage’
should therefore not be checked for a partial page block. We plan
deprecate that parameter officially, please consider if this affects
* Please check that any classes that extend Action or
return the correct value for requiresUnblock().
summarize, in general, the meaning of asking whether a block exists
changed, and any code piece that needs this information should
itself to account for partial blocks, depending on its
Moriel, on behalf of the Anti Harassment Tools
Anti Harassment tools
 For a
discussion of this, see: https://phabricator.wikimedia.org/T210475
Senior Software Engineer, Tech
Community Tech and Anti Harassment Tools
@mooeypoo (IRC /
Reminder: Technical Advice IRC meeting this week **(Wednesday) 4-5 pm UTC**
Question can be asked in English & German.
The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
Michael F. Schönitzer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
I'm not sure if this tool already exist but I'm wondering if there is a
Gerrit plugin that provides a feature for mentioning a Phabricator ticket
on a Gerrit change set and this reveals on the Phabricator ticket itself
like what happens Phab - Phab tickets;
We have Gerrit patch A and Phabricator ticket T -> comment on patch A in
gerrit with ID of T -> Check T (on phabricator) and should see a message
saying "mentioned in patch A (with a link embedded to view patch on gerrit
I would really love this feature as sometimes bugs are fixed and not
referenced so just dropping a comment to the patch (after maybe the patch
has been merged) with the ticket ID should mention it on phab. Or sometimes
some builds fail for some reasons and mentioning the ticket id on the patch
should mention this on phabricator for reference, there are many use cases
but these are just a few. Cc @Paladox
There's been some comments on some old tasks such as T27707
<https://phabricator.wikimedia.org/T27707> about problems with uploading
files that include text metadata that looks like HTML elements.
Years ago, we added security checks for IE 5/6/7 to work around IE's mime
type sniffing: if you went to view a .png file directly in IE (as opposed
to in an <img>) the browser would check the first few bytes of the file to
detect its type, overriding the HTTP Content-Type header. HTML would be
detected with a higher priority than the actual image formats, making it
possible to create an actual .png image which when viewed as an image
looked like an image, but when viewed as a web page was interpreted as
(This was defense in depth in addition to hosting files on a separate
domain; among other things, we sometimes serve files out from the main
domain when dealing with archived (deleted) versions, and third-party
installs are not guaranteed to have a second domain.)
Browsers have moved on, but the code remains and it trips up legitimate
files containing links in metadata, or sometimes just random compressed
data that looks like an element!
I've done a quick research check on feasibility:
* IE 6 and earlier can no longer access Wikimedia sites due to lack of SNI
and TLS 1.0 or later
* IE 7 on Windows XP can no longer access Wikimedia sites due to lack of SNI
* IE 7 on Windows Vista **can** access Wikimedia sites.
* IE 8 and higher support X-Content-Options: nosniff to disable sniffing,
which we already use on all MediaWiki requests.
At some point Microsoft dropped the sniffing, but I'm not sure if it was a
later IE version or an Edge version. No other browsers in reasonably
current versions seem to have this problem.
So the only remaining browser version that might be affected is IE 7 on
Windows Vista, which supports SNI and TLS 1.0. It might or might not still
work once we drop TLS 1.0 some time in the future. (Per our TLS dashboard
1.2% of our connections still use TLS 1.0, but this isn't broken down
between logged-in-user views and anon views.)
* Should we drop the anti-sniff checks on upload?
* If we do, should we forbid logins with IE 7, or something else to protect
the occasional IE 7 logged-in user from a hypothetical targeted drive-by
attack? (Is it actually worth doing work and testing it for this?)
* Should we add X-Content-Options: nosniff on files served from
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2019-01): 364
Active Maniphest users (any activity) in (2019-01): 936
Task authors in (2019-01): 528
Users who have closed tasks in (2019-01): 295
Projects which had at least one task moved from one column to another on
their workboard in (2019-01): 300
Tasks created in (2019-01): 2312
Tasks closed in (2019-01): 2112
Open and stalled tasks in total: 40654
Median age in days of open tasks by priority:
Unbreak now: 14
Needs Triage: 470
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2019-01): 18
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Fri Feb 1 00:01:08 UTC 2019)