[00:00:27] Yeah, I don't think you're the first, but I'm not sure if a specific solution was found [00:00:38] I don't know if anyone has even formally even reported it in our bug tracker either [00:02:58] freephile: Did you ever get that sorted? [00:03:05] Also, why didn't you file a bug in phabricator? :P [00:05:04] Reedy: he just replied to me on github, he said he ran "maintenance/populateContentTables.php" to fix the problem. But It didn't work for me. [00:05:49] You did run update.php as normal though first, right? [00:06:39] What did populateContentTables output? [00:09:29] Filed https://phabricator.wikimedia.org/T224949 for now... [00:09:29] yes, i did. first thing after I update the code [00:10:53] it says "Done. Processed 0 rows in 4.5121569633484 seconds" [00:21:41] compass: is the slot_roles table empty? [00:22:28] :( [00:27:00] Reedy [00:27:21] Yes. It is empty. Is it suppose to be empty? [00:27:32] No, which is where the problem is coming from [00:28:25] Checked our prod server and it's empty as well. It is running 1.31 [00:30:54] yeah, the table is added in 1.31... [00:35:16] So, my 1.31 update script didn't populate it correctly? [00:36:21] I think so, but I don't know enough about the code [00:36:37] It seems it's not completely broken, for everyone. As we'd be having a lot more complaints [00:36:51] But it does seem something is flaky enough in it that it isn't working correctly every time [00:38:33] Any idea how to repopulate it? [00:38:55] The table contents is relatively simple, so you could add the row manually [00:39:06] I just don't know if it just then pushes the problem to somewhere else down the road [00:39:16] The maintenance script/updater should be fixing this [00:42:08] OK. I'll give it a try once I get home. [00:42:29] Did you mean update.php? [00:42:58] I did, yeah [01:14:28] hello is there any reliable programatic way to tell if mediawiki has installed a database already? [01:19:10] aanderse_: maybe you should tell us more about what you are trying to do [01:19:17] TimStarling: sure, great [01:19:26] i'm trying to automate the process of installing mediawiki [01:19:32] basically [01:19:42] i have a script which will run every time the server starts up [01:19:59] at that point i don't currently know if the mediawiki database has been installed or not [01:20:30] sorry, i should say i don't know if the mediawiki script has run to install tables into the mediawiki database or not [01:20:36] the database will always exist, even if empty [01:20:44] i have a predefined LocalSettings.php which is created ahead of time [01:21:13] in hopes of preventing the user from having to go through the web installer to fill out database details, etc... [01:21:46] i'd like my script which runs every time the server starts to basically say "if mediawiki tables have not been installed yet, install them" followed by "run update.php" [01:21:56] so you just want something simple and specific to your setup? [01:21:56] is there a reliable way to do this? [01:22:24] TimStarling: well, i'm packaging this for an odd linux distro... but the LocalSettings.php is generated ahead of time based on predefined input [01:22:56] can the user edit the database name and table prefix? [01:23:20] either the user has defined the database name and table prefix ahead of time, or they just used the distro defaults [01:23:37] i've been looking at maintenance/sql.php and so far that looks to be my best bet... [01:23:53] so far i'm at: [01:23:55] sql.php --query "SELECT COUNT(DISTINCT table_name) as count FROM information_schema.columns WHERE table_schema = 'mediawiki';" | grep -i count | awk '{ print $3; }' [01:24:02] (for mysql, of course) [01:24:22] if i go that route i'd need to write a query for each db type i guess [01:24:49] oh ok, you allow the user to select DBMS? that makes things more interesting [01:25:09] yes, the user has choice on that [01:25:18] i'm assuming upstream supports the advertised dbs? [01:26:54] so is it reasonable to execute maintenance/tables.sql to install a db if i detect there are zero tables in the chosen mediawiki database? [01:26:59] I would lean quite heavily towards recommending MySQL [01:27:10] Support is a strong word. [01:27:32] they're not supported equally [01:27:34] MySQL/MariaDB support in MediaWiki is most likely to work [01:27:36] Krenair: TimStarling: i'll be sure to add a warning that other database types are not recommended by upstream then, thank you for the advice :) [01:27:59] IIRC we had tests using SQLite [01:28:31] ah, ok [01:29:00] I think the thing to do would be, in PHP: [01:29:37] exit( wfGetDB( DB_MASTER )->tableExists( 'user' ) ? 0 : 1 ); [01:30:12] using eval.php (I don't really like doing this, I see it more as a UI, but everyone does it): [01:30:27] echo "exit( wfGetDB( DB_MASTER )->tableExists( 'user' ) ? 0 : 1 );" | php eval.php [01:30:59] or you can make a new maintenance script: [01:31:17] require __DIR__ . '/commandLine.inc'; [01:31:23] exit( wfGetDB( DB_MASTER )->tableExists( 'user' ) ? 0 : 1 ); [01:31:32] it's just two lines of code as its own script [01:32:25] wow, thanks TimStarling, i think that is really helpful [01:32:36] i was looking at the schema and saw user has been there forever [01:32:50] so just use it as an indicator should be pretty solid then [01:32:57] glad to hear it from someone in the channel :) [01:33:18] yeah, it is called mwuser on postgresql because user is a keyword, but the abstraction layer knows that and maps the table name [01:33:26] using PHP you get that sort of thing for free [01:33:28] also, was not aware of eval.php, so thats great [01:33:33] yeah, that helps for sure :D [01:35:02] and sorry, to confirm, i can just execute maintenance/tables.sql to "install" the database? [01:35:29] assuming an empty database is available, all files are installed, and i have a preconfigured LocalSettings.php with all relevant detail, that is [01:35:31] no, definitely not [01:35:35] ok [01:35:38] use maintenance/install.php [01:36:05] i was having some troubles with maintenance/install.php given LocalSettings.php already exists [01:36:37] i'm assuming i made some sort of mistake with the syntax [01:37:11] yes, it bombs out with: A LocalSettings.php file has been detected. To upgrade this installation, please run update.php instead [01:38:29] just checking the source, you'll have to move it away or patch the relevant code [01:39:28] ok, i was looking at some pretty hack previous attempts at packaging this and the prior person had called the sql.php with tables.sql [01:39:53] but you're saying even if i've installed all files in place and preconfigured LocalSettings.php that is definitely not enough, correct? [01:40:34] the main problem is that some tables need to have initial data in them, and tables.sql only has the schema definition [01:40:45] TimStarling: thank you for confirming [01:41:11] the minor problem is that maintenance/tables.sql is only for MySQL and SQLite, for PostgreSQL you would need a different file [01:41:36] yes, i did notice that and that would be easy enough to swap depending on what database type the person chose [01:43:34] TimStarling: where was that file located you think i can patch to drop the LocalSettings.php check? [01:43:41] sorry, i'm entirely unfamiliar with this code base [01:44:26] I'm just reading the code myself to see if there are other ways to do this [01:44:41] i really appreciate your time and effort [01:45:11] in includes/installer/CliInstaller.php there is execute(), it says [01:45:17] $vars = Installer::getExistingLocalSettings(); [01:45:17] if ( $vars ) { [01:45:18] $this->showStatusMessage( [01:45:18] Status::newFatal( "config-localsettings-cli-upgrade" ) [01:45:18] ); [01:45:18] } [01:45:45] maybe you could patch out those 6 lines [01:49:24] another possibility is to make $IP/LocalSettings.php to be actually missing always, and at runtime, to load the LocalSettings.php file from some other place [01:49:50] $IP here is the source root [01:49:58] you can tell the site where to read LocalSettings.php from? [01:50:09] because currently it is just symlinked in [01:50:48] curiously, when install.php checks the existence of LocalSettings.php, that's always in the source tree, but when it later writes it, that's configurable [01:51:29] the location of LocalSettings.php is set by defining MW_CONFIG_FILE in an entry point wrapper [01:51:33] WebStart.php has: [01:51:38] if ( !defined( 'MW_CONFIG_FILE' ) ) { [01:51:39] define( 'MW_CONFIG_FILE', "$IP/LocalSettings.php" ); [01:51:39] } [01:51:52] sorry I should have said, this is for normal runtime now, the installer has its own special rules [01:52:21] ok so i applied the patch to ignore those lines [01:52:25] the idea is that you have the source tree outside the document root [01:52:39] inside the document root, you have a wrapper which looks like [01:52:52] it still tried to write a LocalSettings.php which failed though [01:52:55] define( 'MW_CONFIG_FILE', '/etc/mediawiki/LocalSettings.php' ); [01:53:00] ok [01:53:07] require '/usr/share/mediawiki/index.php'; [01:53:13] can MW_CONFIG_FILE be an environment variable? [01:53:21] no [01:53:28] ok [01:53:30] I mean, the wrapper could have [01:53:36] right [01:53:43] define( 'MW_CONFIG_FILE', getenv('MW_CONFIG_FILE')) [01:53:46] but yeah it is looking for a define [01:53:47] ok [01:54:40] you can set where install.php writes its new LocalSettings.php to on the command line [01:54:58] install.php --confpath=/tmp or whatever [01:55:14] then it will write /tmp/LocalSettings.php which you can delete [01:55:37] yeah --confpath /dev/null seems to throw an error, heh [01:55:42] using /tmp will be fine [01:55:55] i can force a private tmp directory via systemd [01:56:02] so credentials won't be leaked [01:56:44] sed -i 's|$vars = Installer::getExistingLocalSettings();|$vars = null;|' includes/installer/CliInstaller.php [01:56:53] so... that actually works reasonably well [01:57:04] i just have to specify all input stuff twice [01:57:11] like db credentials, wiki path, etc... [01:57:17] not the end of the world [01:59:31] well TimStarling you've been so incredibly helpful [01:59:37] thank you once again for your time and energy [01:59:44] no problem [02:00:03] i'll be sure to ping you with a greatful mention when i finish this up (hopefully in the next few days) [02:00:06] have a nice evening [12:01:24] kostajh: hey, have you seen this? https://community.sonarsource.com/t/end-of-life-of-mysql-support/8667 If you Sonar on production, we need to have posgres, sqlite, or something similar for production [13:35:50] Amir1: thanks, I updated T215178 [13:35:50] T215178: Install SonarQube on tools.wmflabs.org - https://phabricator.wikimedia.org/T215178 [13:37:22] kostajh: thanks. Why not a dedicated VPS in cloud VPS? that would make things really easier [13:37:55] Amir1: that sounds fine to me, do you want to suggest that on the task? I'll rename it so it's not specific to tools [13:38:14] yeah sure, I will write in-depth [13:40:30] Amir1: thanks. I updated the task with an idea about how to handle the per-patch analysis problem with the self-hosted instance. [13:40:51] Awesome! [13:40:56] Thank you [13:47:58] Amir1: thank you! :) btw, we are chatting in #wikimedia-codehealth if you want to join that channel [13:48:18] kostajh: just joined, thanks! [14:55:10] Hi. I need a little help if I'm in the right place to get it. I tried #mediawiki-tech but was denied as it's an invite only channel. I have created a template on a wiki I work on (we're running MW 1.29.2 according to Special:Version). [14:56:19] The template is supposed to add pages to which it is added, to a category (it's for tracking socks), but it doesn't always put the pages it's used on, into the category concerned. I can't figure out what I've broken. [14:56:55] job queue related? [14:57:50] Not sure. I've got some pages tagged which have been done a couple of weeks now, and they're still not in the category. I'm just wondering if it's something to do with the coding of the template. [14:58:23] This is the template: https://en.vikidia.org/wiki/Template:Sockpuppet [14:58:56] It was copied from the french Vikidia, and translated to English. [14:59:23] Does purging/null editing a page fix the categories? [14:59:29] No. [14:59:54] I've tried purging both the page on which the template is added, and the category - neither work [15:00:43] It doesn't do it all the time - some of the pages are where they're supposed to be, but some aren't. It's really confusing as I can't see any difference in what I'm posting when I add the template. [15:02:16] Got an example? [15:02:45] Hang on and I'll pull one. [15:04:09] Reedy: https://en.vikidia.org/wiki/User:No_Vandalism [15:05:07] Should be in the category: https://en.vikidia.org/wiki/Category:Sockpuppets_of_DoveSmith123 - but they aren't. [15:05:14] https://en.vikidia.org/w/api.php?action=query&meta=siteinfo&siprop=statistics [15:05:45] !jobqueue [15:05:45] The Job Queue is a way for mediawiki to run large update jobs in the background. See http://www.mediawiki.org/wiki/Manual:Job_queue [15:06:16] So does that mean there's 9 jobs running, or 9 jobs waiting? [15:06:25] 9 waiting [15:06:39] Is there any way of finding out what those jobs are? [15:07:01] there's a showJobs.php maintenance script [15:07:07] Which can split them by type [15:08:42] I have no idea how to do that, even as an admin. I think I'll refer that up to one of the technical side our end. I imagine one of our French boffins, Plyd or Linedwell will know what they're doing. [15:10:17] Thanks for the help on that one, I guess we've got stuff hanging around that simply hasn't got done yet. Although given how slow our RC moves, I'm surprised anything at all is waiting! [15:11:23] DaneGeld: Depending on your config, jobs are only run at certain times [15:15:14] Ah. Well I don't know when they're run - I have nothing to do with the backstage stuff, that's definitely up to our server crew. [15:57:45] hi everyone. is there a way on the mediawiki api to get specific template text rendered and just get the output, without extra structure? [15:59:51] extra structure? [19:06:04] hi, my wiki got attacked by spam bots (again) and last time I was able to clean it up with BlockAndNuke and running maintenance scripts to remove the deleted revisions and then the unused users, but this time around the users aren't getting deleted... I would like some help in debugging this [19:06:55] there are >1400 users that show up in the user list that have been blocked, but still seem to be there. It appears that most of them have no contributions, so I can't figure out why removeUnusedAccounts.php isn't flagging them for deletion [19:49:17] fdarling: can't help, hopefully someone else can [19:50:30] fdarling: What version of MediaWiki are you on? Is it the same version as the last time you tried to run the script/