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.
Thu, Dec 13
Fri, Nov 30
Wed, Nov 28
Thu, Nov 15
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.
Sep 14 2018
Sep 12 2018
Sep 9 2018
Sep 6 2018
Sep 5 2018
Sep 2 2018
Looking at https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php$13068, the temporary dblist should also exclude nonglobal.dblist.
Sep 1 2018
T174241: AWB no longer works on Wikia aka FANDOM
Aug 24 2018
It's most likely a bug in iOS. I can reproduce it, with https://phab.wmfusercontent.org/file/data/qqvmtekknxnpbfwtap7q/PHID-FILE-rxk2etm7k467bhv3g2ot/Dockerfile.template.
It's the same file, but the one in the task description now returns a 404.
I'm using iOS 11.4.1 on an iPad Mini 2. Only Safari explicitly shows this error, Chrome just shows ERR_FAILED.
Aug 22 2018
Aug 20 2018
This is not an issue that can be resolved on the MediaWiki side of things (unless SMW sent you here - in that case, please reopen and add a link). It is literally impossible to access the database during installation because MediaWiki doesn't know which database it should access, and where that database is located! Semantic MediaWiki should recognize if it is running in the installer, and if it is, prevent loading from the database.
Aug 19 2018
Aug 18 2018
This prevents usage of traits in maintenance scripts, some (like @Legoktm's) PatchFileLocation trait.
A workaround is to manually require_once the necessary traits, but that's ugly, and in my opinion unnecessary.
Aug 12 2018
It seems more likely that a query failed to join with the actor table, or that fails to include the actor_name field.