I've been a Wikipedia editor since 2002 on the English Wikipedia and a few other Wikimedia projects (see my personal account). In May 2012 I joined the Wikimedia Foundation as the "Product Manager" for the VisualEditor Team (now called the Editing-team). I'm now the Lead Product Manager for the Contributors-Team.
This is a dupe of T207683, right?
Fri, Dec 14
Option 3 sounds sanest in terms of fixing/avoiding the issue without a costly migration.
Thu, Dec 13
This is now live in production for privileged groups (in nag-mode for existing passwords, and enforcing for new passwords).
Soft deprecation done. Next is removal from use in Wikimedia production, then hard deprecation, then removal (in MW 1.35 if we get the rest done by MW 1.33).
Local look-ups still work:
Now done, with a prefix:
Yes, https://doc.wikimedia.org/oojs-ui/master/php/ hasn't worked for since September.
Wed, Dec 12
Cookie-licking this for the Infrastructure team.
This looks done:
Cormac is working on this.
Sorry, have updated the link to be a proper one that should last: https://logstash.wikimedia.org/app/kibana#/dashboard/default?_g=(refreshInterval%3A(display%3AOff%2Cpause%3A!f%2Cvalue%3A0)%2Ctime%3A(from%3Anow-7d%2Cmode%3Aquick%2Cto%3Anow))
Tue, Dec 11
Can we delete all the 1.33-wmf.8 branches? They're cluttering up auto-completes etc..
Now that T211237 is resolved, this is fixed in Beta too:
Now hot-deployed to production. Seems fixed to me.
@daniel can give more details about the inner parts of Wikibase, but we had to disable this to unbreak WBMI :-(
Marking as Resolved. Will re-open T204748 instead, pending on Daniel's comments about needing to change things in Wikibase. :-(
This also works in safemode – https://zh.m.wikivoyage.org/wiki/%E7%AB%B9%E5%8C%97?safemode=1 – so it's probably a site script/default gadget that's broken.
Mon, Dec 10
Sorry, good point.
Done in 434432324ff0ffd12718a90d9a7943eb5155f145 ish, right?
So this is now fixed by emergency-disabling the extension. I've written the patches to de-deploy it, but I'll wait for sign-off from the team that this was an intended consequence of their work. https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/478726/
Oops, should have remembered this; my fault, sorry.
Fri, Dec 7
Perhaps, though a date comparison is a little slow. We could do what we did for enabling the visual editor – backfill opt-outs for the small number of accounts that have edited in the past year and then change the default. But it's fiddly.
"An editor has suggested that this needs a citation. Do you have one?" // "Replace with a citation" maybe?
Absolutely. The two standard design affordances on the Web for "this a thing you can click and it will change the page somehow" are blue coloured text with a hover underline effect, and a graphical representation (to some level of abstraction) of a button. This discussion is proposing doing neither of those things.
We don't use PHP 5.x anywhere anymore. Is this still relevant or can we close?
WFM. Maybe "citationNeededInline" vs. "citationNeededEncapsulate" for https://en.wikipedia.org/wiki/Template:Citation_needed_span ?
~/D/c/a/UploadLocal master git log -n 1 Fri 7 Dec 08:19:39 2018 commit 08c2f76ff87466bd3cc63d38abeb8efc0afd8907 (HEAD -> master, origin/master) Author: MarcoAurelio <firstname.lastname@example.org> Date: 2018-12-07 14:22:26 +0100
Worked around for everyone except Firefox. Hopefully Mozilla will eventually fix that issue, but our work here is done.
Thu, Dec 6
This isn't the behaviour on non-VE MediaWiki installations: https://wikitech.wikimedia.org/w/index.php?title=Dell_PowerEdge_1950&action=edit&redlink=1
Another option is to not do this work. I don't see a good justification for letting any users bypass CSP. The ones who will complain the most about this are also the ones who shouldn't be allowed (sysops, interface admins, stewards, …). Yes, toolforge has a number of neat tools, but this is proposing a lot of fiddly work which I don't think adds value.
The only place this is configured (I thought) is https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings-labs.php where 'entityNamespaces' => [ 'mediainfo' => '6/mediainfo' ], is set for Commons; however it's also configured for baseUri to point to https://commons.wikimedia.beta.wmflabs.org/entity/ which doesn't currently dereference, so maybe that's it?
This will be because (to avoid community members complaining), the preference for Page Previews is off by default (wgPopupsOptInDefaultState) on Wikipedias, and there's a special setting to over-ride that and set it on for new accounts (wgPopupsOptInStateForNewAccounts). Re-setting preferences doesn't trigger the "this is a brand-new account" hook (and rightly-so), so you lose the preference.
So… my patch for this fixed it locally, but not on Beta Commons – content-not-allowed-here (e.g. "wikibase-mediainfo" content is not allowed on page File:Test-1445021196.521987.png in slot "Main") is still the error I get on trying to add a caption. Any ideas? Maybe related to T211237 brokeness?
Thank you for your work!