It took a while, but I can confirm it works with a new vagrant instance. xdebug 2.7.0 shows up on http://dev.wiki.local.wmftest.net:8080/info.php.

Ah, I incorrectly assumed, that because T216712 wasn't marked as resolved yet, that that hadn't happened yet. I've filed T221923 for that. However, as SRE is off-site this week according to wikitech.org, temporarily reverting https://gerrit.wikimedia.org/r/506121 might help those currently without xdebug.

It was the latter, I updated because of an unrelated reason (needed rMWVAe7f3fd), and after provisioning, I noticed the message.

The change above results in the message Cannot load Xdebug - it was already loaded whenever I run a maintenance script in vagrant. Xdebug was previously added to MediaWiki vagrant in T212045: Vagrant has Xdebug no longer enabled, preventing debugging and code coverage generation, and it appears both are actually loaded.

I quote from https://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS:

We love whitespace.

Maybe related to T219248: Codesearch index for operations/puppet may be outdated/T219264: Puppet repo not being updated on github?

Might be related to T219248: Codesearch index for operations/puppet may be outdated.

Sound suspiciously like T218918: Some interface messages (e.g. sitenotice, others) are loading old revisions of their messages, which had rMWf8dc579261dc: Only load latest revision in MessageCache::loadFromDB merged as solution.

This is happening with other repositories too, such as rEOTP, rSVEC, and rMW.

https://www.mediawiki.org/wiki/User:Fbstj/T76641 does no longer show this issue, nor do my tests today: https://test.wikipedia.org/wiki/User:Mainframe98/Sandbox. (Using HHVM - PHP7 beta feature temporarily disabled)

In T214522#5008916, @Nikitrain wrote:

In T214522#5008731, @Aklapper wrote:

• Find a way how to locally set up Phabricator to look like Wikimedia's production instance on phabricator.wikimedia.org, as we likely do not want to "play" / manipulate real data

I need some help with this. How can I locally set up Phabricator.

Also my machine have i5, 7th gen and AMD Radeon (It isn't much powerful) graphics card. Is that enough for this task?

It wouldn't ordinarily, but with T217692: labtestweb2001: Fatal error: unknown class AuthPlugin in /srv/mediawiki/php-1.33.0-wmf.20/extensions/LdapAuthentication/LdapAuthenticationPlugin.php on line 21 in mind, having all wikitech copies inaccessible would not be a desirable situation.

There's more trouble. Trying to view my user page shows

Usually, translation requests are handled on translatewiki. If you have an account, you can make the changes to the translation yourself.

Search on the page for the phrase (might require opening the navbox) and you'll find it in the navbox United States articles, coincidentally my first thought on the "culprit" so to speak, which links to United States Electoral College.

It appears the role is broken right now though, as trying to run vagrant provision after enabling it results in an error:

$ vagrant provision
==> default: Running provisioner: lsb_check...
==> default: Running provisioner: file_perms...
==> default: Running provisioner: shell...
    default: Running: vagrant-shell20190219-16700-65z8oe.sh
==> default: Running provisioner: puppet...
==> default: Running Puppet with environment vagrant...
==> default: /usr/lib/ruby/vendor_ruby/puppet/util.rb:49: warning: Insecure world writable dir /vagrant/srv/arcanist/bin in PATH, mode 040777
==> default: Info: Loading facts
==> default: Error: Evaluation Error: Resource type not found: Nginx::Site at /vagrant/puppet/modules/role/manifests/https.pp:10:20 on node wmfprodvagrant.mediawiki-vagrant.dev

I took a look at the code indicated by the stack trace, and it indicates that a header does not match the expected format of a key-value pair. In this case, the value is missing. The stack trace also mentions the requests are coming from the thumb.php end-point, so that should help narrow down what part of the code is at fault. Based on the [[ https://secure.php.net/manual/en/function.headers-list.php | documentation for headers_list ]], only header allows setting invalid headers, so

In T216200#4962775, @Krinkle wrote:

Most likely cause: rMW262fd585d0e6: Improve performance of ActiveUsersPager query / T199044

The instructions are out of date, since T204336: Convert SwiftMailer to use extension registration. I've updated them.

This functionality already exists to a certain degree in MediaWiki, in MediaWikiTestCase::truncateTable.

In T213934#4887396, @Aklapper wrote:

Please [[phab:|report bugs]] if you see them.

[...] Small nitpick: Please avoid linking to the generic Phab front page. :) [https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=projecttag1,projecttag2 foo] could be more helpful (full URL as ? breaks stuff when using [[internal|links]]).

This should probably go in Tech News, as the HHVM beta feature was too. It could repurpose from issue 39, 2014:

'''Recent software changes'''
* You can test a new [[Special:Preferences#mw-prefsection-betafeatures|Beta Feature]] called PHP7. It should make editing faster. Please [[phab:|report bugs]] if you see them.

All it would need is a link to a message on the mailing list, like done for HHVM: https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-September/000948.html

In T154789#4824254, @thiemowmde wrote:

I mean, what is even the problem we are trying to solve here?

Late, but I found another stuck commit: rPHDEP98d9126923d5, from rPHDEP Phabricator Deployment.

@PlavorSeol, then lets make that happen!

And to add insult to injury, reverting back to the most recent commit before rMWVA3488e5 breaks vagrant entirely, requiring a combo of vagrant destroy && vagrant up to get a working environment.

@PlavorSeol, thank you for testing.
It appears that patch-vote_ip-extend.sql isn't SQLite compatible.

I can reproduce on Google Chrome 70.0 this using the arrow keys, and I can reproduce this on the OOUI Demos page with the NumberInputWidget using the scroll wheel. From what I understand, (I believe it was @matmarex who mentioned it) this is caused by the way JavaScript handles numbers: All numbers in JavaScript are represented as floating point numbers (a double, to be precise). The problem is that floating point calculations are never accurate, and the observed drift is due to small rounding errors that accumulate.

Tasks for MediaWiki-extensions-CentralAuth that desire the opposite to happen: T37220: Allow per-session log out and T51890: Logging out on a different device logs me out everywhere else.

A note that popped up during the review of 358425: ParserMigration aims to migrate Wiki text content formats, so not just the Wiki text content model. Any check should ensure that it does check against the content format, as extensions such as ProofreadPage use the same content format, but a different content model, and benefit from this extension.

No, this happens because of T30856: Remove classic edit toolbar from core.

Presumably caused by rETRAb2586aebd94d: Avoid untidy calls to OutputPage::addWikiText(). Cc'ing @cscott as author of the patch.

Same error as with T207928: PHP fatal error when deleting a translatable category on MediaWiki.org.

It appears that everything has returned to normal again. For me at least, as visiting the main page in Italian: https://www.mediawiki.org/wiki/MediaWiki?uselang=it, still shows the incorrect version. I can only imagine that there are incorrect versions for other languages.