[00:45:00] i wanted to ask something about api, but https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=&list=recentchanges&rcnamespace=0&rcprop=title%7Ctimestamp%7Cids%7Cuser&rctype=categorize returns zero results [00:45:34] so i have two questions, firstly, why is this result empty, and secondly, there is something else that i want to ask after i see at least one result [02:18:28] Anyone know anything about why all (non-block-exempt) users might start matching the oldest ban in the wiki? It happened after I updated my integrated phpBB forum and Auth_phpBB extension for compatability [02:30:27] Getting in way over my head here, previously planning never to get into maintaining the wiki side of the site myself [04:33:07] NGC_6205: greetings [04:33:36] hello [04:39:36] NGC_6205: what is the oldest ban on the wiki? What is its ban mask or target? [04:40:42] It's apparently arbitrary, as I unblocked the oldest one (because like a decade old, so why not), and all regular users now show they match the next block, and they are just regular single user blocks [04:41:23] it even tells them they are matching someone else's name [04:42:41] only thing I can think is somehow the changing authentication somehow broke includes/Block.php or something to match everything [05:15:33] interesting [05:15:48] can you disable these two forum extensions and check for the issue? [05:23:09] not sure if I can without also breaking other stuff [05:24:58] break your other stuff for a sec, just check what happens with the blocks then [05:30:40] only way I could think to unlink them easily was to comment out the lines added to my LocalSettings.php for the shared account extension, but then I can't log in at all to test it [05:32:19] Sveta: but actually, yeah, must be that extension somehow, because if I log in before disabling it, the block disappears when I try to edit from regular account [05:45:42] NGC_6205, hmm, thats too bad, i don't have a clue how that extension works [05:45:50] do you know which one of the two is causing the problem? [05:47:56] well phpBB itself is separate software in its own directory; only the Auth_phpBB extension uses its database to share accounts [06:01:51] perhaps inquire with the extension developer to see if they can reproduce the issue [06:18:42] maybe I'll try a newer single sign-on plugin [06:32:34] Well, I have a partial fix... only problem is that this new plugin messes with the case of usernames... [06:36:41] or easy setting, :p [06:41:42] at least I can now cross of the most stressful high priority bug of the upgrade... [07:17:29] I'm struggling to get MariaDB database schema updated from 1.31 to 1.32. There are some RevisionStore changes (so, old schema and new schema). One option is to use $wgMultiContentRevisionSchemaMigrationStage to keep using old schema. Another option is to set that to the new schema and run migrations, as said on this page https://www.mediawiki.org/wiki/Manual:$wgMultiContentRevisionSchemaMigrationStage. However I either get RevisionAccessException, [07:17:29] same as this one https://www.mediawiki.org/wiki/Topic:Uvtlb8b13u3a6uw8 or my login ends up broken (says username was not found, even though it does exist in the user table). I am running Mediawiki in Kubernetes using their official Docker. Does anyone have any tips? [12:32:39] Hey everyone. I'm kind of a mediawiki newbie but I somehow managed to install a container for its 1.32 release with the VE extension (using the 1.32 git branch) and a companion container with parsoid. Everything has looked great for some time, but now, saving an edit in VE raises an "Unknown error" message (although the edit is correctly saved, as [12:32:40] I can confirm after reloading the page). I used the dev console in FF and saw that the JSON response indeed contains "result:success". However, the JSON is followed by a "Notice" in HTML that mentions "Uncommitted DB writes". How would one go about understanding the cause of this issue, and maybe solving it ? Is there a way to list these "uncommitt [12:32:40] ed writes" ? [12:44:34] I imagine the two errors aren't connected [12:47:43] Well, on the contrary, I believe they are: the PHP Notice being in HTML, it creates a parse error on the JSON response and the display of the "unknown error" message... [12:48:48] I mean, the HTML in concatenated to the JSON response. I'm not sure I'm explaining myself quite clearly here. Sorry -_- [14:01:33] Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: @bd808 - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [14:51:11] Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @bd808 - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [19:07:09] Hey. Any idea why could cause "Import failed: Upload of import file failed. The file is bigger than the allowed upload size." with mediawiki 1.33? Happens if the file size is 2.8MB even so it is way under the limit [19:48:49] iAdam1n: You sure? :) [19:49:14] case UPLOAD_ERR_INI_SIZE: [19:49:15] // The uploaded file exceeds the upload_max_filesize directive in php.ini. [19:49:15] return Status::newFatal( 'importuploaderrorsize' ); [20:03:31] max upload size is one of those unfortunate things that can be set 10 different ways in 10 different places. mediawiki vars like $wgMaxUploadSize, or php settings for upload_max_filesize or post_max_size, OR in your webserver's config. all over the place. :( [20:04:05] phpinfo() should be able to help you track it down. [20:16:54] It was fixed now but thanks