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 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
Mon, Feb 11
Thu, Feb 7
The instructions are out of date, since T204336: Convert SwiftMailer to use extension registration. I've updated them.
Wed, Feb 6
Mon, Feb 4
Sun, Feb 3
Wed, Jan 30
Thu, Jan 24
This functionality already exists to a certain degree in MediaWiki, in MediaWikiTestCase::truncateTable.
Wed, Jan 23
Mon, Jan 21
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.
Oct 8 2018
Off-topic(-ish): I've noticed a lot of Tasks about PolyGerrit short coming's, that will be solved by newer releases of Gerrit, helpfully answered by @Paladox. Whenever WMF switches to the new version of Gerrit (T205784), we can close those tasks by the dozen. Is it helpful to move those tasks to a separate column on Gerrit so we can clearly indicate that they are issues solved when we switch to the new version and close them all at once?
I'm sure @Paladox will know for sure, but looking at the new version, (as run by the developers of Gerrit) it appears that the relation chain (same topic/merge conflicts) will move below the commit message when the browser window is narrow.
Oct 7 2018
Alright, that helps narrow it down. The exception states that Class 'Http\Adapter\Guzzle6\Client' not found, but it is present in the php-http package downloaded by composer on my install.
For the extension (not MediaWiki itself)?
This looks like composer has not been run. Looking at composer.json in rEMLG: https://phabricator.wikimedia.org/diffusion/EMLG/browse/master/composer.json, shows that it depends on the guzzlehttp package, is provided through composer.
Oct 6 2018
Oct 4 2018
Oct 2 2018
That is a good point. Actually, I could adjust the patch not to include the change to Hooks.php, to allow the proposed patch to handle that as well. It would make the existing patch a little more focussed too. Does that sound good?
The exception in the task description can't let the user know about that, as that is not something that part of MediaWiki handles. This is something that should be documented on the extension page. Considering support for SQLite should be trivial, that would be a solution for this task. If it is desirable to have the extension show a message (not throw an exception in the script, that would cause trouble) then that is something to address in a separate task.
Running mwscript sqlite.php --check-syntax /vagrant/mediawiki/extensions/SecurePoll/SecurePoll.sql reports:
SQL syntax check: no errors detected.. This would imply that inserting a line above line 23 SecurePollHooks.php containing case 'sqlite': would fix this.
@PlavorSeol Could you test this?
Since this extension was never in Git, there's no Github mirror, Gerrit repo, or Phabricator repository. It didn't have a vagrant entry, translate wiki entry or a CI entry either. I've removed those entries. All that's left to do is archiving MediaWiki-extensions-Preloader
I've updated the extension page. Since the user prefers to use the functionality of Gitlab, we can proceed with archiving MediaWiki-extensions-Preloader .
Looking at https://phabricator.wikimedia.org/diffusion/ESPO/browse/master/includes/SecurePollHooks.php, this is no surprise. The LoadExtensionSchemaUpdates hook does only support MySQL and PostgreSQL for SecurePoll. It uses a switch block for the database type name, which doesn't include an entry for SQLite.
I've done some digging, and for https://www.wikiapiary.com/wiki/ShakePeers and https://www.wikiapiary.com/wiki/LabLynx_Wiki, the variant used is the one provided on https://gitlab.com/troyengel/Preloader. This means that the extension has moved to other hosting means.
Oct 1 2018
Sep 30 2018
This is addressed in the patch for T167722: ParserMigration fails on pages with a content model that is not supported by EditPage.php.
Sep 28 2018
Sep 26 2018
Sep 24 2018
It is documented on Download from Git#Download an extension on mediawiki.org. Feel free to edit it if you think it is in need of improvement.
Sep 23 2018
To get the version for MediaWiki 1.31.0, you'll need to select the REL1_31 branch.
Sep 21 2018
Sep 19 2018
Sep 17 2018
This would make unit testing the service locator very difficult, as well as making unit testing components that require the service locator impossible. Many of such test create a new temporary service locator while leaving the existing singleton instance untouched. Forcing the service locator to be a full singleton basically brings us back to the situation where globals such as $wgUser and $wgTitle were spread all over the code, which made testing a nightmare.
Have you run composer update? AntiSpoof requires wikimedia/equivset to be available, and the error points out that it isn't.
Sep 16 2018
Sep 15 2018
In essence a duplicate of T17212: Allow self-renames.