[01:57:38] How would I be able to run mantinace scirpts from web? [01:58:16] You can't, mostly [01:58:33] Why? (just wondering) [01:58:55] Because they're not designed to be run via the web. Usually due to destructive actions etc [01:59:07] There was an extension to allow doing that, but it's very unmaintained [01:59:22] * BurningPrincess1 nods [01:59:30] Thank you anyway [08:16:19] Are there any MediaWiki administrators online? [08:16:49] https://www.mediawiki.org/wiki/Special:Contributions/Fandom_Fandom [08:17:14] Please check it. [08:18:08] Saroj: looking [08:20:09] gone [14:10:05] Hi there, [14:10:05] I have some issues with configuring the Shibboleth extension with the Shibboleth server of my company. [14:10:06] The webmaster did the configuration for apache server and gave me the following Information: [14:10:06] Email: mail urn:oid:0.9.2342.19200300.100.1.3 [14:10:07] Displayname: displayName urn:oid:2.16.840.1.113730.3.1.241 [14:10:07] Groups as memberOf-Attribut with OID urn:oid:1.2.840.113556.1.2.102 and values like "CN=...,OU=....,DC=...." [14:10:08] Looking at https://lists.wikimedia.org/pipermail/mediawiki-l/2019-September/048129.html I built the following configuration in LocalSettings.php: [14:10:09] not needed <- said webmaster [14:10:11] username attribute is not set [14:10:13] 7.3.19-1~deb10u1 (apache2handler) [14:32:06] I'm not sure if my last message was sent correctly. [14:32:42] Can someone help me with shibboleth integration of a mediawiki instance? (with Shibboleth Plugin) [14:33:22] It doesn’t look very actively maintained [14:34:21] Hmm. GitHub repo maybe not quite as bad as the extension page says [14:36:35] May I contact the developer.. [14:38:10] Our admin says I have to tell Mediawiki its protected by a shibboleth instance. Normally one should be redirected to a ...Shibboleth.sso/Login url for a login form. Which doenst happen [14:38:44] how can i tell mediawiki to use that url? .htaccess? [14:40:31] Which extension are you using? As it seems there’s at least two [14:41:22] This one https://www.mediawiki.org/wiki/Extension:Shibboleth [14:52:36] how can I add CSS classes to a TemplateData documentation rendering? [14:52:53] the specifically [15:31:50] Do I have to tell the AuthManager the Single Sign On url for a Shibboleth login with this extension? If yes, how? [15:32:45] grknight: it already has a class: mw-templatedata-doc-wrap [15:33:50] Vulpix: indeed.. but if possible, i'd like to apply the Bootstrap table class. looks like I'll just have to add missing pieces to the custom skin [15:34:22] the class would be easier [15:38:18] Unless you want to hack the extension to add those classes, there's no way to add additional classes to it. You can add styles to the existing class definition, though [16:09:09] Can a volunteer Mediawiki admin have a look at this edit war? https://www.mediawiki.org/w/index.php?title=Skin:Vector/fr&action=history [16:09:47] A user has decided to change the translate the name of skins used on Wikimedia projects. They are known by their English names everywhere. [16:17:19] Trizek: looking [16:17:34] Thank you. [16:23:08] does Translate seriously prevent me from protecting a translation? I can't protect Skin:Vector/fr and protecting the root does nothing to the translation [16:33:02] As far as I can see the changes weren't restored anywhere after being reverted, so I'm not taking any actions at least for now. [16:34:24] I think a block on the user could be nice (I'm speaking as a volunteer there). This user is known as being conflictual. [16:34:34] He already has been blocked on translatewiki https://translatewiki.net/w/i.php?title=Special:Log/block&page=User%3AVerdy+p [16:42:46] I still don't see any reasons for blocking since there isn't any disruption on mediawiki.org that it would prevent. I did however remove autopatrol since based on their history on mw.o and on other wikis the edits do need patrolling. Again happy to revisit the decision if disruption continues. [17:06:12] Thank you Majavah! [18:52:56] Majavah: you can protect the translation by forcing priority languages other than that language, but blocking the user would be more appropriate if you end up considering such a step. I've placed a warning. [18:53:22] (You can also protect the specific translation unit page, but that's probably going to be confusing for the user.) [22:24:42] Hiya and thanks for the awesome software. Doing upgrades to 1.35.1... In https://www.mediawiki.org/wiki/Download_from_Git#Keeping_up_to_date it is suggested to run 'git pull --recurse-submodules' in each extension and skin directory. Does this not risk accidentally gettinga 1.36 compatible extension that may not be compatible with 1.35.1? [22:26:48] It depends how you install MW... [22:27:46] Reedy: I last upgraded to MW 1.35 via 'git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_35 mediawiki' [22:28:03] and then moving all the stuff needing moving [22:28:46] I did try that 'git pull --recurse-submodules' in extensions/Babel and it fetched the 1.36-branch, which is probably not what I want for a stable functioning wiki [22:29:13] You should just need to run `git submodule update --init --recursive` the root directory [22:29:19] that'll update any of the bundled submodules [22:29:32] oukey dokey. from the top again [22:33:04] 'git submodule update --init --recursive' fetches the 1.36 branch of everything. This is probably not what I want [22:33:21] o_0 [22:33:36] It'll probably fetch... but is it actually switching to them? [22:33:45] noting, there is no 1.36 branch, it's master [22:36:12] Running that ends with complaints about stuff in 'guzzlehttp' getting overwritten and needing to be stashed. I have no notes of ever having edited anything called "guzzlehttp" [22:41:11] the command 'git submodule update --init --recursive' complains "error: The following untracked working tree files would be overwritten by checkout" followed by a 9 files that are at risk of being overwritten [22:49:37] I've never even heard about "guzzlehttp". Here is the output of why/how 'git submodule update --init --recursive' fails: https://paste.debian.net/1179950/ [22:51:46] It's a library that mediawiki depends on [22:51:59] In 1.35.1 we did a library bump [22:52:15] how should I proceed? [22:52:44] OOI, have you used composer to install something else? [22:52:52] Else, what did you "move in" [22:53:20] Nope, composer is only for the needs of the Mediawikis [22:54:53] so.. should I move 'vendor/guzzlehttp' elsewhere and try running the git submodule update again? [22:58:26] I moved it outta the way and that stopped the complaints about that, but now it is complaining that composer/autoload_classmap.php, composer/autoload_static.php and composer/installed.json would be overwritten. I can't figure out where these files are [22:59:02] they're the autoloading files that composer creates for the vendorised code [23:05:09] moved those out of the way and the command ran ok. now running 'composer update --no-dev' but it is making no progress and using no CPU time to speak of [23:05:41] Why are you running composer? [23:07:21] I have scribed in my instructions to run it. I've used these instructions to do many a minor version upgrade, but now these instructions aren't working. Should I approach this like doing a major-revision upgrade (i.e. git clone clean and then move the stuff needing moving there) ? [23:07:46] That probably explains why you got the git errors [23:08:12] the git release branches include a version of vendor, which includes libraries needed by MW core and bundled extensions/skins [23:08:27] so no need to run composer? [23:08:53] If you're using other extensions that aren't bundled by default, you might need to [23:09:17] if you're not, no [23:10:36] but composer will not run ... and trying to run 'php maintenance/update.php' fails with not finding the files I needed to move out of the way to get the 'git submodule update --init --recursive' to run [23:10:59] in one wiki I need composer for Extension:Wikibase [23:11:42] what does git status say? [23:12:50] Reedy: 'git status' says https://paste.debian.net/1179954/ [23:13:13] >Your branch is ahead of 'origin/REL1_35' by 137 commits. [23:13:16] * Reedy squints [23:14:50] I'm stil of the opinion that what's wrong here is that the Mediawiki is 1.35.1, but the extensions are from the master-branch, but then again, I'm not very tech savvy [23:16:26] I can start over again, but I have no idea where these problems are arising from, so if I try the same thing, I'll just get the same broken state [23:17:06] I can't say I've seen any of the MW documents say to use `git pull --recurse-submodules` [23:17:37] * Reedy tests [23:17:55] Ah [23:17:55] https://www.mediawiki.org/wiki/Download_from_Git#Keeping_up_to_date [23:18:15] I think that is fine for master, I bet it's not for release branches [23:18:35] * Reedy tests [23:18:35] yeah, that is probably the issue [23:25:33] hmm [23:25:51] `git pull --recurse-submodules` immediately after `git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_35 mediawiki` and `cd mediawiki` results in no changes [23:40:58] I'm going to revert to backup. I'ma still be up for couple of hours. I am not very techinically adept, but I am extremely grateful for the free software and support and the palette of encyclopediae too [23:45:29] reverted [23:45:49] Hi everybody, after I configure WSOAuth I get this error: [fb8d822cc0043f33289ee97d] /wiki/Especial:PluggableAuthLogin Error from line 116 of /var/www/wiki/w/extensions/WSOAuth/src/AuthenticationProvider/MediaWikiAuth.php: Class 'MediaWiki\OAuthClient\ClientConfig' not found [23:46:13] Anyone knows how to solve it? [23:48:08] run 'composer install' in the WSOAuth extension's directory, or install the extension in a way that includes libraries by default (like the tarball downloaded from mediawiki.org) [23:55:49] tgr_: The latter might be broken as of a recent report.. but I never checked [23:57:10] Mhmm, after I run composer I get "Killed" message [23:58:22] I think lego.ktm fixed the breakage [23:58:45] hi [23:59:46] Galahad: "Killed" means something on your host stopped it... [23:59:57] legoktm cannot be thwarted by a mere dot.