[03:37:54] Good night, I've updated to 1.34.1 and updated MinervaNeue skin as well - it's checked out on REL1_34 but in Special:Version it shows the commit hash for REL1_33 - is there some cache that needs to be purged to properly update? [03:38:23] (if i copy the folder with a different name, then load the copy, it will show the right hash) [04:37:01] matanikob: obvious troubleshooting steps: 1) make sure the files are actually checked out properly and that git didn't throw an error message at you, 2) make sure you run a fetch+pull so that it's the most recent version, 3) restart your webserver in case there's some php opcode caching getting in the way [04:41:14] Hello. If it is demonstrably ethical to do so, is it possible to 1) export a wiki as XML 2) run "sed" to change UsernameA to UsernameB throughout and 3) re-import the wiki? To obscure the existence of edits by UsernameA? [04:41:44] This is a small and barely used wiki [04:42:43] ignorant-tattoo: Special:Export lets you export certain pages as XML [04:43:14] if you want the entire wiki there's a maintenance script for that called dumpBackup.php [04:43:24] And sed, do you think? [04:43:30] I think you're overthinking it though [04:43:34] just install the RenameUser extension [04:43:45] https://www.mediawiki.org/wiki/Extension:Renameuser [04:43:57] then hide/suppress the rename log entry to keep UsernameA hidden [04:44:42] Whatever doesn't leave a trace. I am just very nervous, it is a matter of import [04:44:51] this requires that you assign the 'deletelogentry' right to some user group such as sysop, e.g. $wgGroupPermissions['sysop']['deletelogentry'] = true; [04:45:11] this will not fully remove the trace, you'll need to directly edit the database for that [04:45:20] (your export/sed/import will similarly not work the way you want it to) [04:45:54] BUT UsernameA will be effectively hidden from non-admins by using the extension + deleting the log entry [04:46:04] perhaps that will be sufficient? [04:46:18] Perhaps... [04:46:42] if not, deleting the log entry directly from the database (and from the recentchanges table) would be more robust [04:46:46] I'd have preferred sed but if it's something spookier than that I'll try it out. I am an admin in any case [04:47:02] importing edits to the wiki doesn't overwrite past edits [04:47:21] you'd just create a duplicate set of revisions, one with UsernameA and the other with UsernameB, with both visible in history [04:47:31] I'm operating under the assumption that I'm bribing the server guy and he would just delete the old wiki [04:47:49] You don't have to operate under that assumption if you don't want [04:48:16] I really don't care why you need to do this, just laying out options. The Renameuser route is the most well-supported way of changing a username [04:48:32] All right. I will probably try that. [04:49:40] ignorant-tattoo: oh, one other option. The Renameuser route still lets that user log in and edit as UsernameB. If you want to delete the account entirely, check out https://www.mediawiki.org/wiki/Extension:UserMerge instead [19:43:30] Hi, I'm installed a newly mediawiki, at the moment of install some extensions (MultimediaViewer, CheckUser and ConfirmAccount) not appears in Special:Version [19:43:41] (and yes, I put the code on LocalSettings.php) [19:46:51] Does Special:CheckUser etc work? [19:49:24] Nope [19:49:43] It would sound like you've not enabled them correctly then [19:49:55] Else, they can't be read and the warnings are just being suppressed [19:51:10] Galahad: granted you downloaded the extensions and made sure to load them in LocalSettings.php, maybe you are using PHP-FPM? [19:51:59] yes, are in /extensions and wfLoadExtension( 'CheckUser' ); [19:52:00] wfLoadExtension( 'ConfirmAccount' ); [19:52:00] wfLoadExtension( 'MultimediaViewer' ); [19:52:00] on LocalSettings.php [19:52:19] with PHP-FPM you need to reload it; it will not run new code until the maximum number of clients served by a given process is exhausted [19:52:20] And not, I'm not using php-fpm [19:52:59] but the domain is connected in cloudflare [19:53:10] CF caching it then? [19:53:24] Though, that shouldn't stop Special:CheckUser etc working [19:54:17] Recently purged CF, so nope [19:54:55] could easily check in the headers [19:55:44] also re: CF, you could use Curl to bypass cloudflare [19:56:07] just hit the real IP with Curl's DNS override [19:57:20] You can also test with eval.php [19:57:26] > var_dump( ExtensionRegistry::getInstance()->isLoaded( 'CheckUser' ) ); [19:57:26] /var/www/wiki/mediawiki/core/maintenance/eval.php(78) : eval()'d code:1: [19:57:26] bool(true) [19:59:11] also I think, not sure though, that having OPcache enabled might also affect this [20:00:09] Galahad: have you tried to "touch index.php" in the directory with LocalSettings.php? that would usually force a reload [20:00:10] We use filemtime() on LocalSettings.php, which should usually prevent things like that [20:00:19] oh [20:00:20] Why would touching index.php do anything? [20:00:36] Reedy: opcache/php-fpm react to that by reloading code [20:00:52] [20:52:20] And not, I'm not using php-fpm [20:01:21] wikisp@delta:/var/www/wikisp/maintenance$ php eval.php [20:01:21] PHP Fatal error: Uncaught Exception: Unable to open file /var/www/wikisp/extensions/ConfirmAccount/extension.json: filemtime(): stat failed for /var/www/wikisp/extensions/ConfirmAccount/extension.json in /var/www/wikisp/includes/registration/ExtensionRegistry.php:136 [20:01:32] Permissions, I think [20:01:40] Sounds like it [20:01:47] [20:49:55] Else, they can't be read and the warnings are just being suppressed [20:01:51] ^ aka permissions [20:02:13] I installed from git, so not view that [20:03:42] I am too used to simply getting error 500 when an extension cannot be loaded so did not consider this [20:07:06] Oh, that's not the problem, the problem is extension.json not found [20:07:26] What version of MW etc are you using? [20:08:03] 1.34.1 [20:08:59] Just add the extension.json from repos, but I clone from the repos [20:09:19] I think you use require_once with ConfirmAccount, not wfLoadExtension [20:10:02] Nope, I use wfLoadExtension( 'ConfirmAccount' ); [20:10:07] the extension page says: > Add the following code at the bottom of your LocalSettings.php: require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php"; [20:10:34] Not every extensions has been migrated to the new loading system [20:15:12] I changed the code and not errors when I using eval.php [20:17:28] Same, no load the extensions [20:18:39] var_dump( ExtensionRegistry::getInstance()->isLoaded( 'CheckUser' ) ); [20:18:45] if you run that on eval.php, what does it say? [20:21:26] wikisp@delta:/var/www/wikisp/maintenance$ php eval.php [20:21:26] > var_dump( ExtensionRegistry::getInstance()->isLoaded( 'CheckUser' ) ); [20:21:26] bool(true) [20:38:09] Galahad: check the response headers you get on the Special:Version page [20:38:17] it is probably cached [20:39:22] Remilia, nope, no error shown in Version page [20:43:32] I am not sure how to phrase this [20:44:01] please open developer tools, on the network tab, reload the Version page, and click it in the network tab [20:44:14] on the right there will be Response headers, with cache information [20:45:57] I mean, that eval.php check confirms MW has the extension loaded [20:46:03] No matter what Special:Version has to say [20:48:38] CheckUser extension add CheckUser group in Special:UserGroupRights [20:49:01] but, i view and not are the group [20:49:11] not shown the group [20:50:16] You're not in the group? [20:52:03] No, no. The checkuser group not view in the UserGroupRights list [20:53:42] This seems very specific to your setupp [21:05:16] Reedy, here is my LocalSettings.php, I oversighted the private data (such db credentials and upgrade/secret key) [21:05:20] https://dpaste.org/TTRX [21:05:54] As above, MW has loaded the extension [21:06:06] If it's not showing in the web interface, it's related to your webserver setup [21:11:13] You mean apache2.conf or virtualhost? [21:11:50] It's hard to know exactly [21:12:18] But CloudFlare infront doesn't help with debugging [21:18:43] In last instance I can remove domain from CloudFlare [21:19:59] It's worth doing that for debugging purposes at least [21:22:46] could one use eval.php to get the render output for a specified page? [21:23:02] We've already confirmed it's loading the extension [21:23:07] via eval.php [21:23:12] So it's either on the web side, or the caching infront [21:24:27] I would just add a temporary /etc/hosts entry for the real IP to get around cloudflare but it might not be possible on some set-ups I guess [21:28:13] Galahad: did you enable Development Mode in Cloudflare settings? [21:28:22] that setting disables caching [22:24:47] Galahad: did you enable Development Mode in Cloudflare settings? - nope [22:27:03] I'll try to remove domain from cloudflare [23:12:35] Anyone familiar with dpl? im trying to increase the 500 result count limit, tried with :https://www.mediawiki.org/wiki/Extension:DynamicPageList3, added to localsettings: $wgDplSettings['maxResultCount']=2000, but i still get 500 results [23:12:54] Also tried with $wgDplSettings['allowUnlimitedResults'] =true (still 500) [23:15:07] Have you checked that config value ends up in the config? [23:19:21] There is any way to view the config on the web? [23:20:39] Not really [23:20:44] eval.php is the easiest [23:24:26] That might take too much time (i dont have easy cli access). [23:24:44] WHy it woudlnt get into the config, i just copy-paste the parameter name from the doc. [23:25:17] Merging of config of arrays like that into extension.json can be an issue [23:29:34] Not that [23:29:34] > var_dump( $wgDplSettings['maxResultCount'], $wgDplSettings['allowUnlimitedResults'] ); [23:29:35] /var/www/wiki/mediawiki/core/maintenance/eval.php(78) : eval()'d code:1: [23:29:35] int(2000) [23:29:35] /var/www/wiki/mediawiki/core/maintenance/eval.php(78) : eval()'d code:1: [23:29:36] bool(true) [23:30:20] We don't host the extension, so you'd probably need to ask the maintainers [23:31:09] Which version? [23:31:37] that was HEAD of master [23:33:13] ty