[10:13:46] Hello and BIG thank you, thank you, thank you for the awesomest wiki software [10:14:11] heh :) [10:14:51] I'm trying to upgrade a 1.30.0 to 1.31.0 and I get error "Uncaught RuntimeException: The configuration setting 'wgCaptchaClass' was already set by MediaWiki core or another extension, and cannot be set again by ReCaptchaNoCaptcha." [10:16:25] I have the ConfirmEdit extension installed [10:16:49] from what I'm reading some of the CAPTCHA functionality has been moved to the core. Is this correct? [10:24:02] I'm going to comment out "$wgCaptchaClass = 'ReCaptchaNoCaptcha';" and see what happens when I run the update.php again [10:24:09] I'm not very techincally adept [10:24:19] so I'm just guessing [10:28:47] nope, did not help [10:35:17] I commented out "#wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );" and now the update.php runs [10:35:41] So I gather the ConfirmEdit is now part of the MediaWiki core I guess [10:43:53] jubo2: no, it's not [10:44:31] jubo2: try moving your wgCaptchaClass setting below the wfLoadExtensions call. [10:45:25] you may not actually need that setting any more, not sure [10:45:39] but... did you update the extension when updating mediawiki? [10:45:43] that may be necessary [11:23:24] The first wiki is now upgraded [11:23:47] but I'm having an issue when running update.php on a wiki family [11:24:24] update.php says "PHP Fatal error: Cannot declare class FakeMaintenance, because the name is already in use in /var/www/consumerium.org/develop/w/maintenance/Maintenance.php on line 1556" [11:24:40] oh crap. wrong directory [11:25:35] nope. I'm in the right directory but the error shows the 1.30.0's directory [11:26:34] hmm.. I dunno what is wrong [11:26:38] I google for the error message [11:27:30] to no avail [11:30:32] I have no idea what is class FakeMaintenance and what to do [11:34:03] This problem is probably something to do with the wiki family [11:36:18] jubo2: it looks like you have some kind of mix of old and new code for some reason [11:36:38] jubo2: is it possible that you have more than one copy of mediawiki code? [11:36:40] Googling for "site:mediawiki.org FakeMaintenance yields one hit which does not help [11:37:30] DanielK_WMDE: I have the old wiki code in /var/www/consumerium.org/develop/w/ and the new in /var/www/consumerium.org/develop/www/mediawiki-1.31.0 [11:37:32] Sometimes, people end up having one copy of the code for each wiki in the family. Which can cause a lot of confusion [11:38:31] jubo2: make sure the weay you defined your "family" doesn't cause the old code to "see" the new code, or vice versa [11:38:41] it may be related to environment variables or stuff you have in localsettings. [11:39:03] Most importantly, the $IP variable [11:40:05] DanielK_WMDE: No.. I have only one copy of the Mediawiki code for the wiki family [11:41:56] jubo2: search all directories for "class FakeMaintenance". See if it turns up more than once. [11:42:14] If it's only there once, PHP may be confused because of symlinks [11:42:24] or are you using hard links? [11:46:20] Uhhh.. I don't think I'm using either hard links nor symlinks [11:46:34] The wiki family stuff is all in LocalSettings.php [11:46:54] $IP is hardcoded in LocalSettings.php but ain't that ok? [11:46:58] $IP = "/var/www/consumerium.org/develop/w"; [11:47:55] should I try changing $IP to /var/www/consumerium.org/develop/mediawiki-1.31.0 ? [11:47:59] DanielK_WMDE: ^ [11:50:52] jubo2: when running new code, $IP needs to point to the new code, yes! [11:51:07] otherwise, things may get screwed up in very creative ways [11:51:23] So it is the hardcoding of $IP that is messing things up? [11:51:29] yes [11:51:35] ok. I try that [11:52:54] Yes... now the update.php exited with success [11:53:09] I change the $IP back to the old value and move the directories around [11:53:42] jubo2: if you need your localsettings to work with odl and new code for some reason, you can set $IP based on $wgVersion [11:55:43] Now both wikis of the wiki family are reporting version 1.31.0 so it seems the upgrade worked :D :D [11:55:52] DanielK_WMDE: uhh.. what's odl? [11:58:32] Big thanks for your help DanielK_WMDE! [12:06:22] jubo2: "odl" is just my sloppy typing for "old" ;) [12:09:10] oh ok [12:09:33] It seems the new software is not quite working.. I get Internal error when trying to save an edit [12:09:50] "Fatal exception of type "Error"" [12:10:39] !debug [12:10:39] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [12:10:47] The test.consumerium.org works ok but develop.consumerium.org gives that error [12:10:59] you'll have to enable debug output to get mroe info [12:11:11] or look at the server logs [12:11:15] I upgraded test.consumerium.org first and develop.consumerium.org last ... something somewhere slightly wrong [12:11:52] could be because of extensions. [12:12:04] did you run the update script for both wikis? [12:13:16] DanielK_WMDE: Yes. for both wikis [12:13:48] DanielK_WMDE: The develop.consumerium.org/wiki/ started now working when I added the hardcoded $IP to its config [12:19:11] jubo2: it *should* also work if you don't put an $IP into your LocalSettings at all. well, depending on how your wiki family setup works. [12:19:36] I use symlinks, that works [16:35:59] can i disable using / characters in page names ? [16:37:18] khalella: a "hard" option is: https://www.mediawiki.org/wiki/Manual:$wgLegalTitleChars [16:37:26] note that it will prevent user subpages [16:38:00] khalella: hmm, theoretically there is a config option for it, but disallowing '/' might break some special pages that rely on it for passing parameters [16:38:22] e.g. stuff like https://en.wikipedia.org/wiki/Special:UserRights/Matma_Rex [16:38:38] i actually don't know whether that would be affected, so it might be worth testing out [16:38:46] i just want to prevent users from creating new pages with the name 3/4 [16:38:51] a more sane option would be AbuseFilter [16:38:53] there will be a lot of pages about fractions... [16:38:55] !e AbuseFilter [16:38:55] https://www.mediawiki.org/wiki/Extension:AbuseFilter [16:39:02] right, or TitleBlacklist [16:41:12] hmmm whats wrong with https://www.mediawiki.org/wiki/Help:Bad_title [16:41:19] okay these are good [17:07:15] maybe its just easier to support page titles with / :V [17:07:32] i don't want to break other features [17:11:51] AbuseFilter would let you prevent users from creating pages with / in them in the mainspace without impacting other features such as user subpages [18:53:48] How can I print all years separated with ", " from 2004 to the present year with ParserFunctions?: 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 20018 [18:58:16] David_Hedlund: I don't think there is any loop functionality in ParserFunktions, so if at all you'd have to concoct something with templates and recursion. Although there is a max recursion limit on templates as well, as far as I remember. [18:59:37] * David_Hedlund Looking at https://www.mediawiki.org/wiki/Extension:Loops [18:59:44] FoxT: Thanks. [19:43:47] I'm banging my head against the wall here trying to get rid of the default apache index.html page. How can I replace that so that the Main Wiki page comes up when navigating to the naked domain name. i.e. doc.domain.com? [20:01:27] !debug [20:01:28] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [20:03:47] rockon365: make sure that index.php is before index.html in your DirectoryIndex apache config, or delete the index.html file [20:08:28] Is there a "correct" way to use atomic transactions in MediaWiki's database layer? The API keeps changing and it throws vague error messages. :/ $db->startAtomic(__METHOD__); $db->rollback(__METHOD__); $db->endAtomic(__METHOD__); [20:09:14] Using rollback() now just results in: "Expected mass rollback of all peer databases (DBO_TRX set)". [20:14:23] Skizzerz: thank you. My issue was the path I had for DocumentRoot in my .conf file as well...it was pointed to /var/www/html instead of /var/www/html/wikiname [20:29:45] Got a problem [20:30:08] I needed to comment out these lines from the LocalSettings.php to get the update.php to go through [20:30:30] #wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) ); [20:30:32] #$wgCaptchaClass = 'ReCaptchaNoCaptcha'; [20:31:08] Now the CAPTCHA being triggered is MathCaptcha (I think) (It just asks the user to do a simple arithmetic) [20:32:09] I think I (maybe) should download the latest version of ConfirmEdit extension and try to re-enable it [20:34:29] Yeah.. Now it works [20:36:05] I wonder if there are other extensions that I should reinstall after 1.30.0 -> 1.31.0 upgrade. I have never heard of a sure-shot way to determine if some extensions need to be reinstalled for certain Mediawiki version upgrade. There probably is a way [20:48:06] jubo2: all of them. When updating mw you should update all of your extensions as well [20:51:41] Skizzerz: ok. How do I know which ones require to run update.php ? [20:52:32] run update.php after you finish updating mediawiki itself and all extensions [20:54:51] Skizzerz: does it hurt to run update.php after each extension upgrade? [20:54:59] no, you can do that too if you want [20:55:20] Ok. Thanks for info Skizzerz [20:55:42] you may run into errors though if some extensions are using things that no longer exist (Until you disable or upgrade that extension) [20:57:01] jubo2: you can update mw and extensions at once, when you upload the MW files, upload the extensions as well then run a single update.php run [20:57:13] no need to do seperate ones after each [23:11:45] !hss [23:11:45] https://upload.wikimedia.org/wikipedia/mediawiki/6/69/Hesaidsemanticga2.jpg [23:28:58] Also applies for Symantec