[09:41:58] Hey, I am trying to run a set of unit tests on my local vagrant but I keep getting "Unknown error"s even though my MediaWiki is working perfectly fine, am I missing some configuration that I am unaware of? [09:42:04] https://www.irccloud.com/pastebin/nZ8jLCq0/ [10:08:26] tim_WMDE: WFM [10:08:48] So it would seem things aren't completely broken at least [10:10:24] Hm, odd, I dont remember changing anything about my local installation. I just tried git pull origin master, composer update and running maintenance/update.php with no success [10:11:11] As in, those failed? Or the tests didn't work still? [10:12:15] Same error as in the paste from above [10:12:31] Wikimedia\Rdbms\DBConnectionError from line 1159 of /vagrant/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: Unknown error (127.0.0.1) [10:12:56] Database access works fine in the browser though and "Unknown error" isnt too helpful :D [10:13:30] What more do you need!? [10:13:32] ;) [10:14:41] Suggests the error hasn't been replaced/overridden [10:15:30] $conn = $this->openConnection( $i, $domain, $flags ); [10:15:31] if ( !$conn ) { [10:15:31] // Throw an exception [10:15:31] $this->reportConnectionError(); [10:15:53] tim_WMDE: I guess do some debugging in openConnection [10:16:33] And/or get the connLogger to write out somewhere [10:17:05] Yeah, thats exactly what I am looking at now as well, I will try and see whats happening there [10:17:22] $this->connLogger = $params['connLogger']; [10:17:39] It'll no doubt be something daft [12:50:45] Reedy very daft indeed, still cannot make sense out of it but its tring to use a file name as the database name: tests/phpunit/includes/actions/ActionTest.php DBConnection DEBUG: DB connection error Server: 127.0.0.1, User: wikiadmin, Password: wik..., error: :real_connect(): (HY000/1049): Unknown database 'tests/phpunit/includes/actions/ActionTest.php' [12:52:03] I also dont really get what this ActionTest file is about and how it relates to my tests but yeah, for some reason that appears to be the issue on all my tests, why would PHPUnit even touch this file [12:53:14] Oh no nvm, that was just a random test file I used, but anyway, its still trying to use the file name I supply as the database name [12:54:20] https://www.irccloud.com/pastebin/JV2xfDPQ/ [13:08:12] tim_WMDE: I had a similar problem in vagrant recently. IIRC, I had to provide '--wiki ' on the command line. [13:09:58] Hey, what command do you exactly use to run the tests? I am still a bit of a newbie so if using PHPUnit directly doesnt work then that might be part of the reason why this is happening [13:20:59] I had something like: /tests/phpunit/phpunit.php --wiki wiki [13:32:19] Thanks a lot, that worked! [13:34:00] I am still getting errors though, is there any other upgrade script aside from running "mwscript maintenance/update.php"? I am getting "A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Error: 1146 Table 'commonswiki.globalimagelinks' doesn't exist (127.0.0.1)" [13:46:37] Nvm just got rid of that extension which is good enough for a hotfix [15:37:20] Good morning [15:38:30] Does anyone know why adding session_start(); session_write_close(); to the index.php would break the login system in mediawiki? [15:38:55] Going through the debug file, it seems to authenticate the user correctly, but doesn't properly save the information to the session to keep the user logged in [15:41:48] let's start with the very basics: just *why* are you even thinking of hacking MediaWiki core like that? in any case, provided you're using a somewhat recent version of MediaWiki, you'll wanna read through https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager [15:43:48] That would explain why I'm having issues with it now. Used to use a snippet of code to put our wiki behind a registration wall back on 1.26 [15:44:41] I'd just add it before anything loaded on the wiki index page [15:48:00] tgr here might be able to help you out with AuthManager stuff :) [15:49:10] (as a general rule, though, hacking core should be considered a Bad Idea(TM) as it will complicate the upgrade process and might cause unexpected things to pop up -- you should try to use the appropriate hooks and whatnot to write a proper extension or if there isn't such a hook, add it by submitting a patch against the mediawiki/core repository, get it reviewed & merged...easier said than done, I know!) [15:52:36] I'm surprised that worked on 1.26 [15:53:02] it basically disables session handling, and you need sessions to register/login [15:53:45] It would throw a cookie error, but it worked [16:00:42] I'll be back in a bit, going to head out to lunch [17:05:07] Asking againg, this time with a little more clarity... [17:05:16] Looking for solid plugin/script to migrate DocuWiki-->MediaWiki [17:05:41] But it needs to be for current, or close-to-current MediaWiki builds [17:06:18] I only found something for v 1.9 or somesuch BS [17:15:23] https://www.mediawiki.org/wiki/Topic:Srrpmk18a4jba5fw [17:15:24] https://www.mediawiki.org/wiki/Topic:Rmw5y4misvc7lqqu [17:22:28] So referring back to my original issue: I am trying to put the wiki behind a login form that we have for customers. I wanted to avoid requiring the customers to register for the wiki to view the documentation. The original implementation was to restrict access to the index.php with the code mentioned above with our session based login form. After they'd log in, anonymous wiki users were then able to browse the documentation. What wou [17:24:24] What would be the easiest way to incorporate something like that now?* I have zero experience creating an extension for mediawiki. [17:25:01] !sessionmanager [17:25:02] There is no such key, you probably want to try: !AuthManager, [17:25:11] !AuthManager [17:25:11] https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager [17:25:47] is the docs about how to make extensions that interact with mediawikis auth systems [17:26:21] this can get a bit complex though as it tries to support lots of complex things [17:26:28] I'm not sure I understand the situation [17:26:58] generally if you want to require login you just don't give the anonymous user read rights [17:27:11] I didn't want to use mediawiki's login form though [17:27:42] so what kind of login form do you want to use? [17:32:41] Sorry, had a support call. We have a licensing database that we check against for valid customers / valid software licenses. See https://certainty3d.com/university/ [17:35:48] The login form checks against the licensing, and if valid sets some session variables to keep the user logged in. Which is where I'm running into issues now with the new version of mediawiki [17:38:38] so basically you have no problem with the MediaWiki login form in terms of UX but you want to use a different database? [17:38:55] or you want to use a completely different presentation as well? [17:39:17] A different database [17:40:01] And honestly, the mediawiki login is only used by about ten people for editing [17:43:18] (dinner pause but will try to mock up some code afterwards) [17:43:47] No problem, I appreciate the help [17:46:35] I did find an extension for remote users (https://www.mediawiki.org/wiki/Extension:Auth_remoteuser). Would perhaps using this to auth valid users from our database be an easier approach since this handles auto login / account creation? Then disable anonymous read? [18:55:31] eDavid: so the easiest solution might be to set $wgPHPSessionHandling = 'disable' which completely detaches MediaWiki session handling from PHP, and then you can do whatever you want in index.php [18:56:12] it's not really tested though [18:59:44] I'll give it a shot [19:02:27] Actually, that seems to have worked. Does that restrict the login auth to use cookies exclusively or something? [19:08:53] Oh I see from the documentation now [19:09:33] I guess I'll see if I experience any issues with running that variable ^^ [19:10:09] tgr: I appreciate the help! [19:23:39] eDavid: the nice solution is probably writing a login provider, which might look like this: https://phabricator.wikimedia.org/P7448 [19:24:24] then everyone uses the MediaWiki login form, it checks against your custom database first and if it finds a match it creates a wiki user for that person [19:25:06] and you don't have to worry about security holes like people using api.php instead of index.php [19:25:21] I see [19:26:07] I appreciate the mockup, it seems pretty straightforward to follow [19:31:12] I'll give that a shot next week and see if I can get that running. [19:31:37] Once again, thank you for the help. Have a good weekend [23:49:25] I have a wikipedia dump installed on my mediawiki server, specifically enwiki-20170820-pages-articles-multistream [23:51:37] i used to mwdumper [23:52:04] if i wanted to update to a newer dump would i go about the same process? [23:52:26] just import the new dump and it will automatically overwrite/update old information?