[00:44:27] "Sam: use around..." <- Thank you, this fixed my issue. [03:15:42] Sazpaimon: you can use https://commons.wikimedia.org/wiki/User_talk:Rillke/bigChunkedUpload.js to overwrite via chunked upload [04:57:03] legoktm[m], thanks, I found that earlier. I was looking for something that I can have for all users that would be more user friendly. I can probably use it as a base, though [10:57:30] Can I ask a rudimentary question here? [10:57:31] I know it's probably a very stupid question, but I couldn't find a solution in my research. [10:57:59] please just ask your question [11:01:17] Thank you. [11:01:18] In conclusion, I would like to use composer to deploy some extensions. [11:01:18] docker-compose exec mediawiki composer . [11:01:19] it says that the composer command is not found. [11:01:19] From some articles it looks like composer can be used without any special configuration and I couldn't find anyone having the same kind of problem. [11:01:20] I'm using MediaWiki version 1.35.5 due to its association with certain extensions. [11:02:11] Are there any steps I need to take in order to be able to use composer? [11:02:12] I would be grateful for your help if you could let me know. [11:21:28] Is it installed? [11:22:19] And on path [11:23:48] which docker image are you using? [11:28:31] After running docker-compose up -d from docker-compose.yml, no special installation was done for composer. [11:28:32] The image I used is mediawiki:1.35.5. [11:29:44] https://hub.docker.com/_/mediawiki [11:29:45] I am aware that it is 1.35.5 here. [11:32:52] I suspect that those docker images don't contain composer, and you'd need to build your image (possibly based on them) to install composer [11:33:45] It would seem a bit odd [11:34:19] dross_jp: FWIW, 1.35 is very much supported. So don't worry about that [11:34:57] https://github.com/wikimedia/mediawiki-docker/blob/269d548860091142bff2e16353632918766a6f3a/dev/README.md#shared-volume [11:35:02] >Additionally if a composer.lock and a composer.json are detected, the container will automatically download composer and run composer install. Composer can be used to install additional extensions, skins and dependencies. [11:37:35] Thank you for your answer. [11:37:35] I will check out the link you provided as I'm a bit behind in my understanding. [12:29:16] Anyway... it seems that my current configuration does not include composer.lock. I wonder if this is the reason why it won't install composer... [12:29:17] I simply created docker-compose.yml by myself based on the official image, but it seems that I don't understand it well enough, so it might be better to use the DockerFile as it is, like the link you provided. [12:29:36] Has it checked out the vendor git repo? [12:34:18] Is it my current environment? [12:34:19] No. I made docker-compose.yml by myself and installed it based on a personal blog with no follow-up on Japanese extensions, which I think was a big mistake now. [12:35:34] MW literally can't run without composer and/or that git repo being closed... [12:35:49] So I'm not really sure how this has apparently worked... Unless it used composer on your local machine, rather than in your image [12:38:36] Reedy: doesn't the docker library image just download the tarball from releases. with vendor/ included in it? [12:39:01] you don't even need a local clone of core, it's all in the docker image [12:39:09] I have nfi [12:39:14] I've never used it :) [12:39:29] but that would answer that question [12:43:19] https://github.com/wikimedia/mediawiki-docker/blob/master/dev/docker-entrypoint.sh#L210-L217 [16:08:16] I cannot save in VisualEditor. When I try to save I get: "Error contacting the Parsoid/RESTBase server (HTTP 302)". I'm using MediaWiki 1.37.1. Saving with the normal editor works correctly. Help? [16:09:43] 302 implies that something weird is going on with your rewrite rules or webserver config [16:10:31] so that's where I'd look [16:11:20] cslr: the way VE works internally, mediawiki will make an HTTP call to itself as part of saving. That internal HTTP call seems to be getting a 302 Moved Temporarily response [16:11:26] so that's what you'll need to diagnose and fix [16:12:06] I have only rewrite rule to switch HTTP requests to HTTPS. I will try to tweak that then. [16:12:18] checking access logs would be a good first stop I think so you can see exactly what it's requesting [16:41:18] I found the error. I was using a self-signed HTTPS certificate on the internal server and it was not updated to be a trusted CA certificate so I had to update /etc/ca-certificates.conf and run update-ca-certificates. Now https connections on the server doesn't fail when VE are used and it works correctly. :) [16:41:57] It might be good idea for VE to support non-trusted https connections as the rest of the MediaWiki seem to do. [16:45:24] it'd be good if VE ditched the weird "let's make an actual HTTP request to ourselves" and did something more normal [16:45:37] :) [16:47:01] anyway I'm like 90% sure it's possible to do that in some way/shape/form but may need a bit of PHP code instead of just config. Been a hot minute since I looked at the buggy mess that is MediaWiki's HTTP request code [17:12:17] internal traffic should probably not need to use https [19:08:48] CindyCicaleseWMF: hi, I believe https://github.com/wikimedia/mediawiki-extensions-DisplayTitle/commit/6def2dbfee56823a63dead16a5d54ca30e2157c8 may have caused an issue for us [19:09:17] causes citations to mess up with the cite extension (making them always display as ampersand (&)) so should probably be reverted for now until it can be fixed. [19:09:48] https://github.com/wikimedia/mediawiki-extensions-DisplayTitle/compare/d480066d0a3729b7e2c2d9ddf8ed8b6fc7f3e8fb...6def2dbfee56823a63dead16a5d54ca30e2157c8 was our diff between working and not [19:14:25] Example: https://beta.betaheze.org/wiki/Cite (confirmed DisplayTitle causes that) [22:13:20] is it possible to allow a certain class of users to only be able to add and edit pages in a particular namespace? [22:14:42] https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_editing_of_an_entire_namespace [22:15:55] so  I could use $wgNamespaceProtection[NS_PROJECT] = array( 'super users' ); to make it so that you have to be a "super user" to edit a particular namespace? [22:16:59] avoid spaces, and that configuration variable tells which *permissions* you need to edit that namespace, not groups [22:17:12] you'd also need to assign that permission to the groups you'd like to edit via $wgGroupPermissions [22:17:52] can I put arbitrary text as a permission for a group, or does it have to be one of the "canonical" ones? [22:18:25] so could I add "unrestricted_edit" as a permission, then require it? [22:18:30] you can create your own permissions, so yes you can do that [22:18:54] if creating your own, there is one final piece to the puzzle: $wgGrantPermissions [22:19:28] that's used for BotPasswords and OAuth (if enabled) for write API access, so if you neglect to put your new permission in there the nobody will be able to edit project pages via the API when using a BotPassword [22:19:35] hopefully I can find out how to that in miraheze [22:20:46] what file do I need to modify $wgGrantPermissions in? [22:20:56] all of that goes in LocalSettings.php [22:21:11] on miraheze you will obviously be limited to what they allow you to modify via their management pages [22:21:40] so it may not be possible do undertake any of the above steps without their assistance [22:21:41] oh. So I can't go find the PHP file on the server, and add it in myself? [22:22:07] er, is this a wiki you are hosting yourself, or are you hosting it at miraheze? [22:22:19] second one [22:22:20] because you don't have access to the server in the latter case [22:23:16] ah right right. [22:23:16] maybe it's more effort than it's worth to try to ask them to let me do that? [22:23:31] I'd ask, worst-case they tell you no [22:23:41] It'd be up to them to evaluate it [22:24:18] I would try to give it as straightlined as possible, to make their life easier [22:24:43] usually easy requests are more likely to be granted :) [22:24:54] Got it. So I'm asking for them to allow adding custom permission definitions in the interface? [22:25:15] and you would want to set the $wgNamespaceProtection [22:28:53] RhinosF1: thanks for letting me know! That patch fixed a different bug, so reverting would reintroduce that bug. I will take a look at the interaction with Cite. [22:30:29] CindyCicaleseWMF: thank you. I rolled our setup back before your patch but I can deploy a fix whenever. [22:33:05] RhinosF1: great! I'll ping you when I have something to test. It may be a couple of days before I have time look at it, but I will try to get to it ASAP. [22:33:13] np