I use MediaWiki in Dutch. If I ever claim to see something you don't, check if it occurs when setting the user language to Dutch, and remind me to switch too, so we don't get a repetition of T207288. And if I have the bright idea to test something on my local vagrant machine, and it doesn't work, I probably have a messed up vagrant instance and should be reminded to reset it, so we don't get a repetition of T207288.
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.
Wed, Apr 17
Sat, Apr 13
Fri, Apr 12
Thu, Apr 11
We love whitespace.
Fri, Apr 5
Wed, Mar 27
Mar 26 2019
Might be related to T219248: Codesearch index for operations/puppet may be outdated.
Mar 23 2019
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.
Mar 20 2019
Mar 18 2019
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)
Mar 15 2019
Mar 7 2019
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
Mar 6 2019
Usually, translation requests are handled on translatewiki. If you have an account, you can make the changes to the translation yourself.
Mar 5 2019
Mar 4 2019
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.
Mar 2 2019
Feb 28 2019
Feb 25 2019
Feb 22 2019
Feb 21 2019
Feb 20 2019
Feb 19 2019
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 documentation for headers_list, only header allows setting invalid headers, so
Feb 11 2019
Feb 7 2019
The instructions are out of date, since T204336: Convert SwiftMailer to use extension registration. I've updated them.
Feb 6 2019
Feb 4 2019
Feb 3 2019
Jan 30 2019
Jan 24 2019
This functionality already exists to a certain degree in MediaWiki, in MediaWikiTestCase::truncateTable.
Jan 23 2019
Jan 21 2019
Jan 17 2019
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
Jan 16 2019
Jan 14 2019
Dec 28 2018
Dec 21 2018
Dec 16 2018
@PlavorSeol, then lets make that happen!
Dec 15 2018
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.
Dec 13 2018
Nov 30 2018
Nov 28 2018
Nov 15 2018
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.
Nov 3 2018
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.
Nov 1 2018
No, this happens because of T30856: Remove classic edit toolbar from core.
Oct 25 2018
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.
Oct 21 2018
Oct 19 2018
Oct 18 2018
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.
Oct 17 2018
@Aklapper I've done some investigating in the comment above. Additionally, the same behaviour occurs in Microsoft Edge, Internet Explorer 11 and Google Chrome (70). Also on Google Chrome on an iPad, and Android Phone, all latest versions of them.
This is really strange. So when in Incognito mode, the expected sidebar shows. When logging off, the expected sidebar shows. When logging back on, the sidebar with the incorrect messages is shown again. It's not a script either, using ?safemode=1 has the same issue.
I can only reproduce this on a few devices, I suspect whatever it is, is slowly disappearing with wmf.24. If you think it is safe to proceed, please do so.
The stack trace I've provided is not relevant to this issue, but please do check https://www.mediawiki.org/wiki/MediaWiki, and observe that the sidebar still doesn't show the expected text.
Oh, that stack trace is probably bogus. My local vagrant instance is messed up, as the issue only pops up when literally visiting MediaWiki:Sidebar. I've intermittently had problems with the actor migration process for a while now. I'm sorry for putting everyone on a false track here.
Oct 16 2018
Oct 13 2018
As a quick workaround, setting raw => true and then defining default as '‌0' does show the expected value, as PHP can't coerce the 0 to an empty string anymore.
I'm posting here instead of at a separate task, because I can't decipher whether this is a regression, side effect, bug or anything else. As a result of a3d6c1411dad, a lot interface messages (as in, messages actually used in the interface) are no longer cached. This results in a whopping amount of 172 database queries for interface messages on Special:Version on MediaWiki-Vagrant using MW master a3d6c1411dad or newer. Compared to the 10 there were before, this is a 1620% increase. As every query ends up in the debug log, both the Query overview and debug log tab of the debug toolbar have become rather difficult to use.