There are two places the default value for an extension-specific preference can be specified:
(1) DefaultUserOptions in extension.json
(2) onGetPreferences (or whatever function hooks GetPreferences) in MyExtension.hooks.php
Which is better?
If you do it in both places, and the defaults are in conflict, evidently onGetPreferences wins. This can be seen as follows:
In extension.json add
"DefaultUserOptions": {
"BeSilly": false
}
In onGetPreferences add
$preferences['BeSilly'] = array(
'type' => 'toggle',
'label' => 'Be silly',
'section' => "$sillySection",
'default' => true
);
The result is that the checkbox is checked by default. If you omit the default from extension.json and include it only in onGetPreferences, the result is the same.
It seems that using onGetPreferences is preferable, since the default can be combined there (encapsulated) with the other information about the preference, while putting the default in DefaultUserOptions separates it from the related information, a dependency to be avoided unless there’s some advantage I’m missing. Putting it in both places is at best redundant.
However, the documentation in https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences appears to recommend $wgDefaultUserOptions or DefaultUserOptions. While it shows one example of specifying 'default' in onGetPreferences, it also shows an example in which 'default' is not specified in onGetPreferences. So what’s best? I don’t want to use onGetPreferences for the default if a future version of MediaWiki is going to turn that into a mistake. Also, does DefaultUserOptions serve any purpose, if onGetPreferences accomplishes the same thing better?
Thanks in advance for any advice or clarification.
Tom
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wenlin(a)wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
Hello,
Over the past several days an individual has continued to attempt disruption of Wikimedia Services. The Wikimedia Foundation’s incident response processes are activated and countermeasures are in place. There have been a few times where brief service outages affecting Gerrit and Phabricator were necessary. We are working around the clock to safeguard all systems.
We are putting a series of countermeasures and protections in place to limit the potential impact of similar activity going forward. We aren’t at liberty to provide more detail right now without putting our efforts at risk, but will update you again when we can.
Please report any suspicious activity to security(a)wikimedia.org <mailto:security@wikimedia.org>.
Thank you!
Respectfully,
David Sharpe
Senior Information Security Analyst
Wikimedia Foundation
📘 Read on Phabricator at
https://phabricator.wikimedia.org/phame/live/1/post/141/
-------
How’d we do in our strive for operational excellence? Read on to find out!
- Month in numbers.
- Current problems.
- Highlighted stories.
## 📊 *Month in numbers*
* 7 documented incidents. [1]
* 30 new Wikimedia-prod-error tasks created. [2] (17 new in Jan, and 18 in
Dec.)
* 27 Wikimedia-prod-error tasks closed. [3] (16 closed in Jan, and 20 in
Dec.)
There are in total 177 open Wikimedia-prod-error tasks today. (188 in Feb,
172 in Jan, and 165 in Dec.)
## 📉 *Current problems*
There’s been an increase in how many application errors are reported each
week. And, we’ve also managed to mostly keep up with those each week, so
that’s great!
But, it does appear that most weeks we accumulated one or two unresolved
errors, which is starting to add up. I believe this is mainly because they
were reported a day after the branch went out. That is, if the same issues
had been reported 24 hours earlier in a given week, then they might’ve
blocked the train as a regression.
→ https://phabricator.wikimedia.org/tag/wikimedia-production-error/
Below is breakdown of unresolved prod errors since last quarter. (I’ve
omitted the last three weeks.)
By month:
- February: 5 reports (1.33-wmf.16, 1.33-wmf.17, 1.33-wmf.18).
- January: 3 reports (1.33-wmf.13, 1.33-wmf.14).
- December 2018: 5 reports (1.33-wmf.9).
- November 2018: 3 reports (1.33-wmf.2).
- October 2018: 1 report (1.32-wmf.26).
- September 2018: 2 reports (1.32-wmf.20).
By steward and software component:
Core Platform:
* Parser: https://phabricator.wikimedia.org/T216664.
* Revision backend: https://phabricator.wikimedia.org/T214035,
https://phabricator.wikimedia.org/T212428.
Growth:
* Echo: https://phabricator.wikimedia.org/T217079.
* Flow: https://phabricator.wikimedia.org/T212742,
https://phabricator.wikimedia.org/T204793.
* Page deletion: https://phabricator.wikimedia.org/T203913.
Wikidata:
* Wikibase: https://phabricator.wikimedia.org/T217329,
https://phabricator.wikimedia.org/T215380,
https://phabricator.wikimedia.org/T213483.
* WikibaseLexeme: https://phabricator.wikimedia.org/T207479,
https://phabricator.wikimedia.org/T200906.
* WikibaseQualityConstraints: https://phabricator.wikimedia.org/T212282.
Performance:
* Lib-rdmbs: https://phabricator.wikimedia.org/T212284.
Multimedia:
* MediaWiki uploading: https://phabricator.wikimedia.org/T208539.
Fundraising-Tech:
* CentralNotice: https://phabricator.wikimedia.org/T209741.
(Nobody - pending code ownership process):
* ImageMap extension: https://phabricator.wikimedia.org/T217087.
* Nuke extension: https://phabricator.wikimedia.org/T212690.
## *️⃣ *Fixed exposed fatal error on Special:Contributions*
Previously, a link to Special:Contributions could pass invalid options to a
part of MediaWiki that doesn’t allow invalid options. Why would anything
allow invalid options? Let’s find out.
Think about software as an onion. Software tends to have an outer layer
where everything is allowed. If this layer finds illegal user input, it has
to respond somehow. For example, by informing the user. In this outer
layer, illegal input is not a problem in the software. It is a normal thing
to see as we interact with the user. This outer layer responds directly to
a user, is translated, and can do things like “view recent changes”, “view
user contributions” or “rename a page”.
Internally, such action is divided into many smaller tasks (or functions).
For example, a function might be “get talk namespace for given subject
namespace”. This would answer “Talk:” to “(Article)”, and “Wikipedia_talk:”
to “Wikipedia:”. When searching for edits on My Contributions with
“Associated namespaces” ticked, this function is used. It is also used by
Move Page if renaming a page together with its talk page. And it’s used on
Recent Changes and View History, for all those little “talk” links next to
each page title and username.
If one of your edits is for a page that has no discussion namespace, what
should MediaWiki do? Show no edits? Skip that edit and tell the user “1
edit was hidden”? Show normally, but without a talk link? That decision is
made by the outer layer for a feature, when it catches the internal
exception. Alternatively, it can sometimes avoid an exception by asking a
different question first – a question that cannot fail. Such as “Does
namespace X have a talk space?”, instead of “What is the talk space for X?”.
When a program doesn’t catch or avoid an exception, a fatal error occurs.
Thanks to D3r1ck01 for fixing this fatal error. –
https://phabricator.wikimedia.org/T150324
💡*ProTip*: If the Jenkins build is failing for a project and you suspect
it’s unrelated to the project itself, be sure to report it to Phabricator
under “Shared Build Failure”, or use
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?project=share…
.
## 🎉 *Thanks!*
Thank you to everyone who has helped by reporting, investigating, or
resolving problems in Wikimedia production. Including: Aaron Schulz,
Addshore, Alaa Sarhan, Amorymeltzer, Anomie, D3r1ck01, Daimona, Daniel
Kinzler, Hashar, Hoo man, Jcrespo, KaMan, Mainframe98, Marostegui, Matej
Suchanek, Ottomata, Pchelolo, Reedy, Revi, Smalyshev, Tarrow, Tgr,
Thcipriani, Umherirrender, and Volker E.
Thanks!
Until next time,
– Timo Tijhof
🍏 *He got me invested in some kind of.. fruit company.*
-------
Footnotes:
[1] Incidents. –
https://wikitech.wikimedia.org/wiki/Special:AllPages?from=Incident+document…
[2] Tasks created. –
https://phabricator.wikimedia.org/maniphest/query/a0yuo6bqDOrh/#R
[3] Tasks closed. –
https://phabricator.wikimedia.org/maniphest/query/7pmQcTvTWw_4/#R
Hi everyone!
I am pretty sure I am missing something obvious here, but I cannot spot it
and I would appreciate a fresh set of eyes looking at it.
The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js is
the backbone of a OOUI-based tool. I have made quite a few of a these tools
in the past with no problem. For now, this tool is only supposed to do two
things: add a link to the "More" dropdown on the top of the page (only if
it is a user talk page), and open a OOUI dialog once the link is clicked.
The first part works and I have verified that the *createWindow* method is
called when you click the link, but the dialog is not shown. Can someone
kindly look at my code and tell me what I am missing?
Thanks,
Huji
I'd like to say thanks to the folks who have been working on VisualEditor,
Citoid, and Parsoid in the past few years.
When I first started to work in 2015 on what I eventually called the LearnWiki
project
<https://meta.wikimedia.org/wiki/Grants:IEG/Motivational_and_educational_vid…>,
I was a bit hesitant to recommend VisualEditor due to it having some rough
spots in performance and reliability, but I knew that VE was probably the
way of the future for new Wikipedia contributors. As I've been writing
scripts recently for a 2019 small pilot project that will teach users how
to create citations with VE
<https://meta.wikimedia.org/wiki/Grants:Project/Rapid/Pine/Continuation_of_e…>,
I've been impressed by how much has improved. The VE's performance seems to
be faster, the automatic citation tool can be easy and enjoyable to use,
and the system (VE + Parsoid + Citoid) seems to be generally stable on ENWP.
I think that you made the desktop user experience significantly better for
new contributors on ENWP who use VE.
While I'm writing, I'll ask a couple of related questions. If someone knows
of recent research that analyzes the productivity and longevity of new
users who try the VE and/or New Wikitext Editor ("NEWT") interfaces, I
would be appreciative if that information could be added to this project
talk page
<https://meta.wikimedia.org/wiki/Grants_talk:Project/Rapid/Pine/Continuation…>
so that I can take a look. Especially interesting would be research that
shows points in workflows on English Wikipedia where new editors who use VE
seem to become stuck. (The sticking points may have more to do with
policies than with interfaces.) Also, Guy Macon has asked some questions here
(a secton of the same talk page)
<https://meta.wikimedia.org/wiki/Grants_talk:Project/Rapid/Pine/Continuation…>
regarding the percentage of editors that use different editing interfaces.
Please participate on the talk page if you have the time and interest.
Thanks again for the good work on VisualEditor and related systems.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
Hello,
On 16 March 2019, Wikimedia Foundation staff observed suspicious activity
associated with Gerrit and as a precautionary step has taken Gerrit offline
pending investigation.
The Wikimedia Foundation's Security, Site Reliability Engineering and
Release Engineering teams are investigating this incident as well as
potential improvements to prevent future incidents. More information will
be posted on Phabricator (https://phabricator.wikimedia.org/T218472 ) as it
becomes available and is confirmed. If you have any questions, please
contact the Security (security(a)wikimedia.org <trustandsafety(a)wikimedia.org>
).
Thanks
Wikidata surpassed the English language Wikipedia in the number of
revisions in the database, about 45 minutes ago today.I was tipped off by a
tweet [1] a few day ago and have been watching via a script that displays
the largest revision id and its timestamp. Here's the point where Wikidata
overtakes English Wikipedia (times in UTC):
[ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d
www.wikidata.org -r 888603998,888603999,888604000
revid 888603998 at 2019-03-20T06:00:59Z
revid 888603999 at 2019-03-20T06:00:59Z
revid 888604000 at 2019-03-20T06:00:59Z
[ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d
en.wikipedia.org -r 888603998,888603999,888604000
revid 888603998 at 2019-03-20T06:00:59Z
revid 888603999 at 2019-03-20T06:00:59Z
revid 888604000 at 2019-03-20T06:01:00Z
Only 45 minutes later, the gap is already over 2000 revsions:
[ariel@bigtrouble wikidata-huge]$ python3 ./compare_sizes.py
Last enwiki revid is 888606979 and last wikidata revid is 888629401
2019-03-20 06:46:03: diff is 22422
Have a nice day!
Ariel
[1] https://twitter.com/MonsieurAZ/status/1106565116508729345
In light of the gerrit incidents these last few days, and as part of
the process of strengthening gerrit's operational security, we 've
just gone ahead and configured gerrit to add the User: HTTP header on
the response. To take advantage of that, we 've also amended the wmf
apache LogFormat directive to log that header if it exists. I 've
documented the change in
https://wikitech.wikimedia.org/wiki/Apache_log_format.
Note that the order of fields changes just a bit (the last field is
now 17 instead of 16, the 16th is now the User: HTTP header if it
exists, otherwise a -). If you are aware of anything that might break
because of that let us know.
Regards,
--
Alexandros Kosiaris
Senior Site Reliability Engineer
Wikimedia Foundation