[11:20:20] omg my shiny new mediawiki is hacked :-( how did these users get created! :-( [11:21:07] I'm guessing they registered themselves? :) [11:21:52] ;-) yea that's my guess too. Thought I had it set to require preregistration... [11:30:16] $wgGroupPermissions['*']['createaccount'] = false; [11:34:51] This might be helpful to remove the spam pages. I'ts green for stable "Extension:DeleteBatch" [11:44:26] GumShoe: have a look at Extension:Nuke [11:44:34] its what is used on the WMF wikis [11:53:57] Ahh nuke distributed with 1.30.0. Just have to load it. [11:54:40] Works nice. Is there somethnig similar to mass delete users? [11:58:18] root@localhost> DELETE * FROM users; :P [11:58:41] (joke, do not try) [11:59:47] I am laughing; ha ha ha [12:05:52] !deleteuser [12:05:52] Deleting users is very messy and not recommended, because this breaks referential integrity in the database (they appear in many different tables like users, edit histories, recentchanges, preferences, etc). A safe solution is to block the users, and possibly rename them with . You can also try [12:06:02] + https://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php　　 [12:06:30] I was having a look at UserMergeAndDelete but it's not on UserMerge [12:08:26] UserMerge can be delete account as merge an account to "Anonymous" (user_id: 0). [12:09:31] In WMF wikis, this function is disabled. " $wgUserMergeEnableDelete = false; " @ CommonSettings.php [12:13:16] !blockuser [12:29:53] Now that I've restricted account creation, deleted spam pages I'd like to change passwords on ~ 20 accounts so they can't login. That way the history will be preserved... How abou this; Extension:EditAccount [12:30:38] or DisableAccount maybe [12:30:52] empties password and email fields [12:31:03] Yes, this looks more suitable to my purpose Extension:DisableAccount [12:40:32] This seems liike an odd way to enable an extension ???? require_once "$IP/extensions/DisableAccount/DisableAccount.php"; [12:48:24] wfLoadExtension() only works for MediaWiki 1.25+ and if the extension has been migrated to extension registration [12:49:02] the docs at mediawiki.org are outdated [12:49:13] use wfLoadExtension, it's migrated [12:49:52] wfLoadExtension( 'DisableAccount' ); [12:49:53] $wgGroupPermissions['bureaucrat']['disableaccount'] = true; [12:49:57] bbl [12:50:40] Thanks for help folks. spam deleted, users blocked. [12:52:21] Now to fix my newly enabled php-fpm that's crashing mariadb for lack of memory. [15:29:23] Technical Advice IRC meeting starting in 30 minutes in channel #wikimedia-tech, hosts: @addshore & @CFisch_WMDE - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [16:20:22] so just to confirm what im reading on the compatibility chart, medaiwiki 1.27 will not work with php 5.4? [16:26:02] EL7 already seems so old, ugh [16:28:01] yeah [16:29:19] very annoying. the "old" server uses fedora 21. i decided for our newer stuff to use a distro better suited for a server, so went with CentOS [16:29:59] but fedora 21 actually has mostly newer versions of stuff, like mediawiki 1.24 vs centos which has mediawiki 1.23 [16:30:53] annoying situation... cant use latest mediawiki or even the oldest LTS versions on CentOS [16:31:31] right now im thinking ill just have to go with mediawiki 1.26 [16:31:50] or just copy the whole damn installation from the fedora21 server and be done with it haha [16:45:41] Dan39: if you have CentOS 7 / RHEL 7, you can install a more modern version of PHP via software collections [16:46:03] or throw it in a container [16:46:12] Skizzerz: i know its possible, but eh :| [16:46:26] annoying [16:46:33] true [16:46:37] thats probably the easy thing to do [16:46:56] but not insurmountable, and still probably easier than switching to a different OS if that ecosystem is what you're used to [16:47:35] and of course the centos people wild scold you for using the other repos outside of like epel/elrepo [16:49:36] well, if you go the software collection route, you don't risk the reason why they yell at you for that (aka you are guaranteed to not introduce any system instability) [16:49:58] what do you mean "software collections"? [16:50:13] basically they're packages that put themselves in /opt instead of directly in /usr/bin, so they don't override system packages [16:50:18] but you can configure apache to point at them, etc. [16:50:23] right [16:50:29] its not just a 3rd party repo? [16:50:35] (for cli usage, they have a shell script you can source in .bashrc to make them default in your path) [16:50:49] the repo is maintained by the centos team: yum install centos-release-scl [16:51:05] I think [16:51:13] well the repo name is right [16:51:17] idk if the team actually maintains them or not [16:51:49] o really, ill see if i can do that [16:52:07] i always grab stuff from epel and rpmfusions which can be yum-installed on centos, so are pretty well supported [16:52:14] (most of them are probably ports of the versions in RHEL, which redhat officially supports) [16:52:44] https://www.softwarecollections.org/en/scls/rhscl/rh-php71/ [16:52:48] awesome [16:52:49] doing that [16:53:03] umm.. does mediawiki auto-upgrade my db from 1.24? :P [16:53:31] not automatially, but you can run the update.php script [16:53:37] are you using the tarballs or git? [16:54:38] not sure yet [16:54:42] the existing install was from repos [16:55:28] ah [16:55:40] idk if the repo version is being maintained at all [16:56:14] you recommend tarball or git? i use both of them often. git usually seems like the better choice since i can just do a pull to upgrade :P [16:56:47] if you're familiar with git, imo go with git, as it makes upgrading easier [16:56:54] the install process is a bit more involved [16:57:00] hmm [16:57:13] ill grab the tarball, might be others that maintain it in future [16:57:21] kk [16:57:42] tarball is easier to install, but a bit harder to (properly) upgrade in the future [16:57:45] thanks for info [16:58:17] (point upgrades are easy, it's the major version upgrades which can be problematic) [16:59:42] for the tarball install, 1) make a db backup, 2) remove/purge the repo version, 3) extract tarball to fresh (empty) directory in your web root. I do not recommend placing the mediawiki files directly in the web root, but rather in a subdirectory (/w is the de facto standard) [17:00:09] 4) check to see if step 2 deleted your database; if it did, restore the backup [17:00:50] 5) browse to /w/mw-config in your browser, plug in db credentials, and it should detect the existing wiki, upgrade it, and generate a fresh LocalSettings.php for you [17:01:40] awesome. sounds easy [17:04:20] for future upgrades, follow the docs on mediawiki.org [17:04:26] !update [17:04:26] update.php is a script that updates the database tables. You usually need to run it after upgrading MediaWiki or installing certain extensions. For details, see [17:04:40] that link (except follow it from the top :P) [17:05:36] coolio, thanks [17:59:46] Skizzerz: php 7.0 vs 7.1, any thoughts? [18:00:28] 7.1 is newer? :P [18:00:52] i just got php70 working and then while looking at packages noticed 7.1 is also in scl repos -_- [18:00:54] derp [18:01:09] (note i just took lunch, it didnt take me that long just to get php installed :P ) [18:01:12] heh [18:01:32] well if you have 7.0 working, look into the changelog, benchmarks, etc. to see if 7.1 brings any improvements in areas you care about [18:01:35] if not, imo don't bother [18:01:40] and just stick with 7.0 [18:02:08] ill upgrade [18:02:13] ill never forget i didnt [18:02:15] lol [18:02:22] note that support-wise 7.0 will end support sooner than 7.1 [18:02:30] right [18:02:40] i think i can just uninstall and reinstall :) [18:02:44] supy easy peasy [18:03:00] yeah [18:03:03] and update paths, etc. [18:03:44] the scls each install to their own dir, so you can have multiple versions side-by-side (so if you wanted, you could have both 7.0 and 7.1 installed, although I can't think of a reason why you'd want that) [18:04:59] hmmm, what the hell is mysqlnd module... [18:05:07] php always have to be changing stuff [18:05:12] what happen to mysqli? lol [18:05:41] mysqlnd is the old mysql extension, you don't want/need it [18:05:55] mysqli is its replacement [18:06:04] success, running php7.1 :D [18:06:52] oh [18:07:01] so they just renamed the old mysql module to mysqlnd... [18:07:20] i recall there being mysql and mysqli modules in php.ini before [18:07:40] the nd is "native driver" iirc [18:08:33] hmm lets see which package provides mysqli... [18:09:10] the mysqlnd package provides mysqli <_< [18:09:13] derp [18:09:16] * Dan39 reinstalls mysqlnd [18:09:49] no value [18:09:52] mysqli [18:09:53] MysqlI Support enabled [18:09:55] Client API library version mysqlnd 5.0.12-dev - 20150407 [18:16:35] i wonder why i dont see using mysql source more often than mysql and mysql says "Bye" when you quit, it is so friendly :D [18:17:21] well, it's mariadb technically [18:25:23] darn, xcache isnt in scl [18:26:36] i wonder if the el php-xcache will work, i highly doubt it [18:29:13] you don't need it, is why [18:29:31] php 7 comes with zend opcache, which is opcode caching, and it should be enabled by default iirc [18:29:35] if you need user caching, check out apcu [18:30:33] ah [18:30:36] hmmm [18:31:51] grrr i dont see a mod_ssl or mod_gnutls package in scl for httpd [18:34:24] i must be missing something, it must be included already [18:34:34] no way they have apache httpd but no damn ssl [18:36:32] found it, httpd24-mod_ssl [18:42:55] There are MediaWiki tables in this database. To upgrade them to MediaWiki 1.30.0, click Continue. [18:42:56] :D [18:43:13] Upgrade complete. [18:48:14] Skizzerz: hmm, im guessing i can skip the Administrator account setup during installation since this is kind of an upgrade? [18:48:15] Someone to help me with my thumbnailing problem ? [18:48:39] or can i skip the entire rest of this... [18:49:34] hmm [18:49:55] Seems that MediaWiki is looking for Thumbnails where they aren't [18:50:10] or Imagemagick/PHP aren't moving them to the correct directory [18:52:29] Dan39: I think it might be required [19:03:07] Skizzerz: didn't seem to work ¯\_(ツ)_/¯ [19:03:14] wiki is working fine, but admin user didnt create i think [19:03:24] right [19:03:28] I think that's correct [19:03:44] it's a required part of the form, but it no-ops on upgrade *shrug* [19:04:04] heh [19:04:14] do you know how i can make myself admin now? [19:04:21] do you not have an existing admin user? [19:05:12] i dont have the login [19:05:22] ah [19:05:23] i just have a regular user login [19:05:35] do you want to make that user an admin, or reset the password of the existing admin? [19:05:40] (or make a brand new admin) [19:05:51] make my user an admin [19:05:54] k [19:06:03] cd to the wiki's maintenance directory in your shell [19:06:04] the original admin is still here :P just told me to migrate this haha [19:06:19] then php createAndPromote.php --sysop --bureaucrat --force --username=YourUserName [19:06:29] awesome, thanks [19:06:32] if your username has spaces in it, surround it in quotes [19:07:22] :) [19:07:33] thanks, though syntax is different it says, i got it figured out [19:07:37] ah [19:07:41] was going from memory ;P [19:07:57] very close [19:08:01] just no --username= [19:08:10] so just php createAndPromote.php --sysop --bureaucrat --force YourUserName [19:08:25] you have been huge help dude, tyvm [19:08:45] (you'll need to log out and back in to make the group changes take effect) [19:09:03] I think [19:11:18] i think it's working [19:11:40] though wow the admin pages are uh... quite rudimentary [19:14:07] there isn't much in the way of shiny UI there, no [19:14:14] it's also very decentralized [19:14:34] (aka there's no central "admin panel" to perform all admin tasks, it's scattered about beyond dozens of special pages and other UI links) [19:14:55] i see [19:15:23] what is version "REL1_31" ? [19:15:37] im guessing 1.30 is below that? [19:16:36] 1.31 [19:16:50] so i guess that's the beta [19:17:01] or just the development branch [19:18:02] development branch is master [19:18:23] if it's already branched off, then it's in the release candidate stage or about to be entering it [19:19:26] I don't see a REL1_31 branch in git so hasn't been branched yet [19:20:12] anticipated release date for 1.31 is June 2018 [19:36:49] Hmm, specifying filetypes hasn't helped either [19:37:51] Does having a subdirectory for the MediaWiki path instead of a subdomain change anything ? [19:52:37] Skizzerz: looks the same as 1.24 -_- [20:18:16] Dan39: I don't quite understand what you're saying. What looks the same as 1.24? [20:32:35] i meant just the overall look over mediawiki [20:32:53] i was hoping for some amazing feature/interface updates haha. i know there is a ton of security updates :P [20:33:00] visit a few special pages, it should look different [20:33:06] e.g. Special:ApiSandbox [21:23:33] Dan39: It's MediaWiki not Windows. :P [21:27:51] want it to look different? Get a new skin, edit the css