[01:36:44] finaly I found the problem [01:37:38] a script from the MediaWikiFarm has thrown an exception resulting in HTTP 500 Internal Server Errors [01:39:46] due to these errors my other wiki did not trust the data from the local commons repository [02:38:07] how can we download particular category tree with url? [13:53:27] Technical Advice IRC meeting starting at 3 pm UTC/5 pm CEST in channel #wikimedia-tech, hosts: @addshore & @Tobi_WMDE_SW - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [13:55:57] Sirs [13:56:05] Any of you know a cool "dark" theme for mediawiki ? [13:56:09] that isnt "dead" ? [13:57:59] As a non-sir, I do not know anything cool. [13:58:13] andre is a SIR name [13:58:19] at least in Portugal :-) [13:58:34] I dont really like white background pages [13:58:40] wanted something a bit little darker [13:59:01] (As a cat / human / fridge, I can choose whatever nickname I want on internet chat...) [13:59:08] :-P [13:59:23] andre__: goat! [13:59:51] Incabell: Oops, you are right. [14:14:46] we're all purple cats on the internet [14:50:46] Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @addshore & @Tobi_WMDE_SW - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [15:34:06] hello [15:35:08] I'm having a problem with an account on a local MediaWiki install, the password cannot be changed even by using the changePassword.php maintenance script. [15:36:03] what happens if you try? [15:36:07] Errors: "* The supplied credentials cannot be changed, as nothing would use them." and "* The authentication data change was not handled. Maybe no provider was configured?" - only happening with this one account. [15:36:40] I tried to google the first message, 4 results and all translations for the variable behind [15:36:45] do you have an extension installed that handles authentication? Such as the LDAP extension? [15:37:05] if so, then you can't change the password through mediawiki, i think [15:37:22] shouldn't be the case [15:37:30] the plugin system for auth extensions was rewritten recently. that may also be a cause. [15:37:47] anomie: do you know what triggers that error? --^^ [15:38:38] Xenthys: What extensions do you have installed? [15:38:56] https://ayy.lmao.pizza/KFZT0Uc.png [15:38:57] It definitely sounds like a problem with an authentication extension [15:39:15] why would it happen only with one account tho? :s [15:39:38] hmm, none of those sound like auth extensions [15:39:44] Oh, only 1 account, that really is weird [15:40:00] it's the main admin account, user ID 1 [15:40:41] Did you change any of the authenticationManager configuration settings to anything weird? [15:41:12] nope, I migrated the wiki to another machine along with the DB but didn't touch auth settings [15:41:31] Did you change versions of mediawiki when migrating? [15:41:33] DanielK_WMDE: "The supplied credentials cannot be changed, as nothing would use them." occurs when no provider accepts whatever AuthenticationRequest is passed into AuthManager::allowsAuthenticationDataChange(). " The authentication data change was not handled. Maybe no provider was configured?" occurs when none of the AuthenticationRequests created from the data passed to User::changeAuthenticationData() result in a successful, non-ignored response [15:41:33] from AuthManager::allowsAuthenticationDataChange(). [15:42:04] bawolff: neither [15:42:26] kik? [15:44:15] the user therefore seems to have no provider at all, how is that even possible and is there a way to fix it? [15:44:44] I performed a database check and no errors were found [15:46:46] Two sanity checks, which you can do using maintenance/shell.php: What does `User::getCanonicalName( $username, 'usable' );` output, and what does `wfGetDB( DB_MASTER )->selectRow( 'user', [ 'user_id' ], [ 'user_name' => $username ] );` output? In both cases, $username is the name of the user in question. [15:46:49] anomie: any idea what could be wrong with Xenthys' setup, then? [15:47:13] will try that now, thanks [15:48:06] uh… the used version doesn't seem to have a shell.php maintenance script [15:48:44] lemme shake the guy who installed it in the first place >_> [15:48:46] Use eval.php then, and put 'return ' before the commands. [15:48:52] oh, ok, thanks [15:49:27] shell.php was added in 1.29, if you're on something older than that then it wouldn't exist. [15:49:50] but wasn't the new auth layer also introduced in 1.29? [15:50:19] AuthManager is in 1.28. [15:51:27] eval.php doesn't print anything [15:51:37] even with a "return 1" [15:51:43] And it was backported to 1.27 too [15:54:24] Are you using HHVM? Anyway, try wrapping it with var_dump( ... ) instead of prefixing with return. [15:54:50] I don't know what HHVM is, sorry [15:56:15] Doesn't do much, just seems to be waiting for more input: https://ayy.lmao.pizza/9vvSp7b.png [15:57:43] That's not how you use eval.php, it is waiting for input. [15:57:47] $ php eval.php [15:57:47] > return 1; [15:57:47] 1 [15:57:55] oh gosh *facepalm* [15:58:22] lol [16:00:11] first eval returns false [16:00:40] second one returns object(stdClass)#192 (1) {["user_id"]=>string(1) "1"} [16:02:18] so if I understand, it is found as user ID 1 but isn't usable for [insert reason here] [16:03:52] as for the use of eval.php, I don't know why I convinced myself it took the line to eval as an arg, sorry about it :[ [16:05:37] Xenthys: what'S the name of the user you ran the second eval for? [16:05:59] Does the username have an @ in it or something? [16:06:08] what even is an unusabel username? [16:06:15] it does have an "é" in it [16:06:24] unicode problem? [16:06:46] that may be a cause, yes [16:07:08] unicode should work, and it does work for user names on wikipedia & co. [16:07:09] Xenthys: It should be fine if in NFC [16:07:14] oh... [16:07:21] this may be related to the database move to a new system [16:07:25] So there's your problem, the username isn't usable so it can't be used. [16:07:32] if its not in NFC it should get autoconverted, but maybe not from eval.php [16:07:39] if you are not very very careful, mysqldump *will* screw up character encoding! [16:08:03] My bet is: encoding of the user name got screwed up in the database [16:08:24] it works with the console encoding, but not with what mediawiki uses internally [16:08:52] hmm, alright [16:09:06] MW normalizes the encoding at the point it retrieves from webserver [16:09:17] so eval.php is probably not normalizing the encoding [16:09:40] any idea on how to fix that, uh, screwed up encoding? [16:09:47] you could maybe get the user by id and then print out the username to determine if it's an encoding issue? [16:09:58] (or drop into a sql prompt and run a SELECT) [16:10:07] if the terminal isn't utf8, we may actually be looking at a more severe screw-up tthan NFC vs NFD [16:10:35] If DanielK_WMDE is right, it probably got converted to iso-8859-1 (as opposed to the NFC thing i was mentioning) [16:10:40] Skizzerz: printing it out is subject to the terminal's character set, and mysql's idea of "conveniently" converting to that character set [16:10:50] true [16:11:04] you can select from mediawiki and put through bin2hex [16:11:06] but it looks like a *nix terminal, so the terminal's character set SHOULD be sane [16:11:08] Xenthys: select HEX(user_name) where... [16:11:46] bawolff: still subject to conversion, if mysql thinks it should be. [16:12:00] even in unicode, iso 8859-1 control character "block" are often printed as their windows-1252 equivelent, so it would probably display "wrong" in a *nix terminal [16:12:32] i think select HEX will tell us what'S actually in the db [16:13:06] can I just, like, edit the username to remove the accent? [16:13:37] sure? (asterisk) [16:14:18] usernames are denormalized in a number of tables. While the user table is the only one that matters in terms of logging in, other tables like the logging and recentchanges tables store the username as well [16:14:37] fwiw, if the hexcode of é is E9, its the wrong encoding, the correct one is C3 A9 [16:14:58] so you can change the username in the user table, you may solve your issue, but things like recentchanges may still show the old username [16:15:04] found C3A9 in the hex [16:15:07] just a caveat to be aware of [16:15:08] no E9 at all [16:15:30] What is the username, maybe something else about it is invalid [16:15:39] ^ [16:16:25] The site owner edited it (still connected on his computer) and it works now, so it was the accent [16:16:47] ok [16:17:37] so the encoding seemed to be right, but still not working well ¯\_(ツ)_/¯ [16:18:05] however the version he uses seems to be old, so it would probably work with the latest one [16:20:33] thank you all for your help, would probably never had noticed it [18:54:11] Is there a proper way to call mediawiki API using LUA in a module? [18:54:21] or is it still done by URL/parsing JSON? [18:55:38] wait, is there a non-proper way to do it? i thought it wasn't possible at all [18:55:46] is it not possible? hmm [18:57:57] I guess a more specific question is: Is there a way to get a list of items from a category (paginated or however) through LUA? [19:11:50] why is url/json not proper? :( [19:15:05] serp: I do not see any API libraries, so manually constructing requests and then parsing the JSON result is probably the best way for now if you absolutely *need* to use the API. I'd try to see if there are alternative ways that don't require additional web requests however [19:16:32] for example, many wikimedia wikis have the DynamicPageList (Wikimedia) extension installed, which will let you get a list of pages in a category [19:17:49] I wasn't the one to ask the original question... i just feel like using the api is proper :) [19:18:25] er derp [19:18:47] both your nick and KataiKou's nick were red on my client and I never looked at the nicks themselves >_> [19:19:04] imo using the API in a lua module should be avoided because it could bog down page saves [19:19:18] and if the webserver is responding particularly slowly may abort the save [19:19:31] or abort the render [19:19:34] not sure exactly what happens, tbh [19:20:01] (probably aborting the rendering of that module, so instead of the results you get a nice lua error message on the page instead) [19:21:51] also security issues [19:23:11] since unlike sitewide js, modules are editable by anyone, you could embed a module in a page with one account (to look like a benign edit), vandalize that page with another account, and then when the admin does a rollback the module detects the editor is an admin and fires off an API request to do something that needs admin perms, like block a mess of users