This was already announced in the last TechCom Radar email, but in case you
have missed it:
In an hour, we will be talking about the hybrid extension management:
You can join the discussion on IRC in the #wikimedia-office channel.
Various problems with ENUM have been presented,
and it appears that its use cases may be better accommodate
in db schemas for MediaWiki by other means.
I'm looking for the following:
* Success stories with ENUM (cases where it's not only good but better than
* Horror stories or scenarios we not yet covered.
These would influence the direction, our options are currently:
* Keep allowing it and encourage it for cases where its good.
* Start discouraging it in general, but document cases for which it makes
* Disallow by default (in policy). New usage would require approval through
some other method (e.g. DBA feedback or some such).
More at <https://phabricator.wikimedia.org/T119173>.
Hooks::run() was soft-deprecated in Nikki Nikkhoui's HookContainer
patch, merged on April 17.  And my patch to remove almost all
instances of it in MediaWiki Core was finally merged over the weekend.
 That means that everyone writing core code now needs to learn how
to use the new hook system.
HookContainer is a new service which replaces the functionality which
was previously in static methods in the Hooks class. HookContainer
contains a generic run() method which runs a specified hook, analogous
to Hooks::run(). However, unlike Hooks::run(), you generally should
not use HookContainer::run() directly. Instead, you call a proxy
method in a hook runner class.
Hook runner classes give hooks machine-readable parameter names and types.
How to call a hook
In MediaWiki Core, there are two hook runner classes: HookRunner and
ApiHookRunner. ApiHookRunner is used in the Action API, and HookRunner
is used everywhere else.
How you get an instance of HookRunner depends on where you are:
* In classes that use dependency injection, a HookContainer object is
passed in as a constructor parameter. Then the class creates a local
$this->hookRunner = new HookRunner( $hookContainer );
* In big hierarchies like SpecialPage, there are always
getHookRunner() and getHookContainer() methods which you can use.
* Some classes use the ProtectedHookAccessor trait, which provides
getHookRunner() and getHookContainer() methods that get their
HookContainer from the global service locator. You can also call
MediaWikiServices::getHookContainer() in your own code, if dependency
injection is not feasible.
* There is a convenience method for static code called
Hooks::runner(), which returns a HookRunner instance using the global
* Extensions should generally not use HookRunner, since the available
hooks may change without deprecation. Instead, extensions should have
their own HookRunner class which calls HookContainer::run().
Once you have a HookRunner object, you call the hook by simply calling
the relevant method.
How to add a hook
* Create an interface for the hook. The interface name is always the
hook name with "Hook" appended. The interface should contain a single
method, which is the hook name with a prefix of "on". So for example,
for a hook called MovePage, there will be an interface called
MovePageHook with a method called onMovePage(). The interface will
typically be in a "Hook" subnamespace relative to the caller namespace.
* Add an "implements" clause to HookRunner.
* Implement the method in HookRunner.
Note that the name of the interface is currently not enforced by CI.
Alphabetical sorting of interface names and method names in HookRunner
is also not enforced. Please be careful to follow existing conventions.
How to deprecate a hook
Hooks were previously deprecated by passing options to Hook::run().
They are now deprecated globally by adding the hook to an array in the
Using the new system in extensions
Extensions should create their own HookRunner classes and use them to
call hooks. HookContainer::run() should be used instead of Hooks::run().
As for handling hooks, I think it's too early for a mass migration of
extensions to the new registration system as described in the RFC.
Extension authors who are keen to pilot the new system can give it a
go. Make sure you add Nikki and me as reviewers.
More information about the new system can be found in docs/Hooks.md
. The patch to add it should soon be merged.
-- Tim Starling
This has been happening since Saturday. Looking for resolution.
Empty patch to demonstrate:
Last merged patch (passed test, insignificant change to php):
TypeError: Argument 1 passed to
PreTaintednessVisitor::linkParamAndFunc() must be an instance of
Phan\Language\Element\Variable, instance of
Phan\Language\Element\Property given, called in
on line 147 and defined in
The third bug in the recent wave of regressions (T253819
<https://phabricator.wikimedia.org/T253819>: Dancing Search Bar in
MediaWiki) is a high visibility bug, it happens at a range of screen widths
on all wikis for any kind of users (readers too).
A reddit video of it
21k upvotes in 2 days.
I think this should be hotfixed as soon as possible: the current behavior
damages the image of Wikipedia.
I've submitted the hotfix on Saturday:
Further steps require +2 access. Today there are 2 SWAT windows left, the
patch is simple, I hope developers familiar with Vector will take swift
Note to reviewer:
The patch simply reverts the rename of `emptyPortlet` class in the JS,
similar to the hotfix of the 2nd bug which reverted the rename in CSS:
Additional note: the CI test fails with an unrelated
'phan-taint-check-plugin' error detailed in the previous email.
Explanation of the issue:
* CSS: `.emptyPortlet` class hides the menu
* JS: removes the `.vector-menu-empty` class instead, which does nothing,
thus the More menu remains hidden.
* The menu collapsing logic's size calculation expects the menu button to
be visible. Without that it decides there is enough space to uncollapse the
recently collapsed tab, thus the dance begins.
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2020-05): 362
Active Maniphest users (any activity) in (2020-05): 1144
Task authors in (2020-05): 586
Users who have closed tasks in (2020-05): 326
Projects which had at least one task moved from one column to another on
their workboard in (2020-05): 322
Tasks created in (2020-05): 2531
Tasks closed in (2020-05): 2462
Open and stalled tasks in total: 44655
* Only open tasks in total: 43592
* Only stalled tasks in total: 1063
Median age in days of open tasks by priority:
Unbreak now: 0
Needs Triage: 563
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2020-05): 9
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
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 Mon 01 Jun 2020 12:00:17 AM UTC)