Hello,
We have requested a 30 minutes read-only window for s8 (wikidata) for the
30th July from 05:00-05:30 UTC to switchover our primary wikidata database
master (T227063)
db1071 is an old host and out of warranty that will be decommissioned
(T217396).
This will also unblock some migration stages of the new redesign for the
wb_terms table (T221764)
We are going to do this on Tuesday 30th July from 05:00 to 05:30 AM UTC (we
do not expect to use the 30 minutes window, if everything goes as expected).
Impact: Writes will be blocked, reads will remain unaffected.
Communication will happen at #wikimedia-operations
If you are around at that time and want to help with the monitoring, please
join us!
Thanks
Hello,
Adam Wight enhanced our MediaWiki test runner (Quibble) so that it now
detects whether an extension / skins has a 'selenium-test' script
defined in package.json. If so, for each repositories it will:
npm install
npm run selenium-test
The feature has been long awaited, that will lets developers upgrade
webdriver.io at their own pace and use their preferred framework (mocha
or cucumber).
Until now, we were running the Selenium tests from mediawiki/core which
made it next to impossible to upgrade webdriver.io.
The task was: https://phabricator.wikimedia.org/T199116
cheers,
--
Antoine "hashar" Musso
Hello,
I've recently noticed that in a wiki farm I look after, about 20% of the
tables are MyISAM, but it doesn't seem very consistent - i.e. some
tables that are MyISAM in some wikis are InnoDB in others. searchindex
and math look to be all MyISAM.
From what I've read about them it seems that InnoDB is the best option,
especially for recent versions. Would it be a good idea to change them
all to InnoDB?
Thanks,
Aran
Dear all,
we’re really happy to announce the first ever Coolest Tool Award
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award>!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and bridge workflow gaps for the Wikimedia communities.
There are incredible many great tools out there. It’s time to celebrate
this & to make the work volunteer developers do more visible to everyone :-)
The Coolest Tool Award ceremony will take place at Wikimania, as part of
the official program:
https://wikimania.wikimedia.org/wiki/2019:Technology_outreach_%26_innovatio…
The award is organized & selected by this year's Coolest Tool Academy. The
plan is to award the greatest tools in a variety of categories: For
example: “best Commons tool” to recognize the value of a tool for a
specific project, or “best newcomer” to award the work of a fairly new
developer.
As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!
Please use this form:
https://docs.google.com/forms/d/1Ip5Sb_CDvgO6IN2f51V3WjkVYU9Sa-nneX5PoY0sjo…
to recommend tools by July 29, 2019.
You can nominate as many tools as you want by filling out the form multiple
times.
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2019_Survey_Privac…
Thank you very much for your ideas & recommendation(s)!
We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!
If you have any questions, please contact us at
https://meta.wikimedia.org/wiki/Coolest_Tool_Award.
Thanks :-)
Birgit, for the Coolest Tool Academy 2019
--
Birgit Müller (she/her)
Director of Technical Engagement
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi,
This week I'd like to thank:
* Daimona, bawolff, and sbassett for their work on v2.0 of the
phan-taint-check-plugin, which has been instrumental in catching real
security issues.
* James_F for picking up a lot of CI maintenance
* MatmaRex for seeing through a patch to allow skins to have custom OOUI
themes, 2 years after beginning work on it!
If there's anyone you want to thank or give a shout out to - please do!
-- Legoktm
TL;DR: The pre-2011 option of setting a ResourceLoaderModule instance in
$wgResourceModules, or calling ResourceLoader->register with an object as
second parameter, will be removed in MediaWiki 1.34.0 (release expected in
Nov 2019). Change these to an array using the 'class' or 'factory' keys
instead. (Examples below.)
This only affects legacy extensions using PHP files to register modules. If
your extension already registers its modules via extension.json, then this
change does not affect you.
-------
During the experimental release of ResourceLoader in MediaWiki 1.16 (2010),
modules had to be registered via $wgResourceModules as an object instance
of ResourceLoaderModule.
In MediaWiki 1.17.0 (2011), as part of the first default-on public release
of ResourceLoader, this was replaced with the ability to register a
declarative array instead. [1] This allowed modules to be lazy-instantiated
by ResourceLoader. These arrays can be class-based (this is the default,
using the 'class' option), or closure-based (using the 'factory' key).
This option was removed as part of refactoring to make ResourceLoader
(more) standalone. I did not want to incur the overhead of maintaining it
for another release cycle through deprecation first. It has been
undocumented since before the first non-experimental release of
ResourceLoader in 1.17.0 (it was kept "temporarily" for compat with
1.17alpha at WMF). No known usage was found in Gerrit-hosted extensions,
nor in any of the Codesearch-index repos hosted externally. It also can't
affect extensions using extension.json for module registration (since MW
1.25).
Examples of the needed conversion:
```
# Before (no longer supported)
$wgResourceModules['ext.Foo'] = new MyModuleSubClass();
$wgResourceModules['ext.Bar'] = new MyModuleSubClass( [
'xyz' => true,
] );
$wgResourceModules['ext.Baz'] = efComposeSomeComplexObject();
# After (PHP)
$wgResourceModules['ext.Foo'] = [ 'class' => MyModuleSubClass::class ];
$wgResourceModules['ext.Bar'] = [ 'class' => MyModuleSubClass::class, 'xyz'
=> true ];
$wgResourceModules['ext.Baz'] = [ 'factory' => 'efComposeSomeComplexObject'
];
# After (JSON, recommended)
"ResourceModules": {
"ext.Foo": { "class": "MyModuleSubClass" },
"ext.Bar": { "class": "MyModuleSubClass", "xyz": true },
"ext.Baz": { "factory": "MyExtHooks::composeSomeComplexObject" }
```
-- Timo
[0] https://phabricator.wikimedia.org/T222637
[1]
https://gerrit.wikimedia.org/g/mediawiki/core/+/dac5084f6d61b6c45bfae491a2b…
- https://github.com/wikimedia/mediawiki/commit/dac5084f6d
Hello,
On Thursday 25th July at 05:30 AM UTC we will switchover our current
primary database master for m3 (phabricator) from db1072 to db1128.+
This is the tracking task for this maintenance:
https://phabricator.wikimedia.org/T228243
db1072, the current db master, is old, and out of warranty and will be
replaced by db1128, a newer and more powerful host.
Impact:
The switchover will require a few minutes of read-only on phabricator, so
nothing will be allowed to be written.
Reads will remain unaffected
Communication will happen on #wikimedia-operations
Thanks
Manuel.