[04:19:43] <jfolv>	 Just found out about Phabricator being essentially shelved. What does MediaWiki and the WMF plan to do in light of this? I know it's open source, but I can understand not wanting to take on the task of maintaining additional software. Either way, I'm interested in what the plan will be moving forward.
[04:39:42] <TimStarling>	 see mmodell's comment at https://phabricator.wikimedia.org/T283980#7123849
[05:57:09] <jfolv>	 TimStarling: Thank you!
[12:49:19] <Guest44>	 Hello I am having problem setting up VisualEditor can someone help me? I am getting Error contacting the Parsoid/RESTBase server (HTTP 400) every single time I  am trying to edit a page. But I do not use RESTBase and have $wgVisualEditorAllowLossySwitching= false; too
[12:50:02] <Guest44>	 Using 1.36, very buffled as it should work "out of box"
[12:50:53] <gryffus>	 Hello, i want to deploy a MediaWiki instance and i would like to deploy it as a docker container. However i can see in wiki statement "Do not run this stack in production! Bad things would happen!". Is there some production-ready docker image and / or guide for deploying into production?
[13:02:28] <gryffus>	 I have discovered this one: https://hub.docker.com/r/bitnami/mediawiki/ . Would you recommend this for production use? Or do you have some other alternative?
[13:07:02] <JavaBean>	 looks like a nice explanation on their part, i too would like to know more
[13:14:57] <lens0021>	 gryffus: Have you tried https://hub.docker.com/_/mediawiki/ ?
[13:27:48] <gryffus>	 lens0021: are these the images built from https://gerrit.wikimedia.org/r/mediawiki/core.git ? This is the one that is not recommended for production of this is the case
[13:28:03] <gryffus>	 s/of/if/
[13:31:06] <lens0021>	 "Do not run this stack in production! Bad things would happen!" is written in DEVELOPERS.md and it is saying about docker-compose.yml only I think
[13:31:31] <gryffus>	 lens0021: yes, this is what i intend to use (compose)
[13:32:02] <lens0021>	 A docker-compose.yml file is in the repository, isn't it?
[13:32:24] <gryffus>	 lens0021: yes
[13:33:01] <gryffus>	 maybe my questions was wrong. If this is development docker-compose.yml , is somewhere also a producion docker-compose.yml ?
[13:33:02] <lens0021>	 the compose file is using  'docker-registry.wikimedia.org/dev/stretch-php72-fpm:2.0.0' not 'mediawiki'
[13:35:07] <lens0021>	 gryffus: I have no idea about it now, sorry for not helping
[13:35:42] <gryffus>	 lens0021: no problem, maybe someone else will shed some mor light into it, lets be patient
[13:40:18] <gryffus>	 I think i will go for the Bitnami compse file & docker images. Although it would be better if i could get some info from someone with experiences in MediaWiki & docker.
[13:46:20] <lens0021>	 does using docker-compose for production have limited functionality? I am not sure the Bitnami compose file is for production.
[13:48:55] <gryffus>	 It should help to establish reproducible deployment scenario. All data should be in persistent volume, so when i delete the image/container and download new one, the container just should start with the new version and old data. Also it helps remembering / saving of configuration between different deployments and/or deployed versions
[13:50:10] <gryffus>	 docker-compose should be the same as docker with specified parameters... Compose file is basically list of parameters with which the container is started
[13:50:27] <gryffus>	 i.e. shared volumes, exposed ports etc
[13:53:32] <lens0021>	 well, I experienced the 'depend_on' clause of my custom docker-compose file is not enough for making the mediawiki instance wait for the backend, database
[13:54:43] <lens0021>	 maybe I was wrong, however i am using HashiCorp Nomad as a orchestration tool now
[13:56:27] <lens0021>	 and docker-compose did not support 'restart_policy' that is supported by docker swarm afaik
[13:56:58] <gryffus>	 I would be happy with sqlite backend... This producion is aimed for 40 users at most
[13:57:17] <gryffus>	 And i do not use a swarm. Only one standalone instance
[14:01:38] <lens0021>	 oh, simple is better, ok
[14:02:31] <moonmoon>	 I wouldn't recommend a sqlite backend for anything bigger than a single-user install
[14:16:17] <gryffus>	 Ok i have tried the default mariadb configuration and it got stuck on "INFO  ==> Trying to connect to the database server" ... Although database container is up and running
[14:17:56] <gryffus>	 Nevermind, wrong rename of database container
[15:38:39] <Frorayz>	 Anyone here?
[15:45:21] <majavah>	 Frorayz: don't ask to ask
[15:46:07] <Frorayz>	 Oh sorry but I am having this problem can anyone help? I am getting Error contacting the Parsoid/RESTBase server (HTTP 400) every single time I  am trying to edit a page. But I do not use RESTBase and have $wgVisualEditorAllowLossySwitching= false; too
[15:46:08] <Frorayz>	 Using 1.36, very buffled as it should work "out of box"
[15:50:35] <Vulpix>	 The error message may be misleading. "Parsoid/RESTBase" means one of the two. If you're not using RESTBase, problem is on Parsoid (through the rest.php intertface that provides MediaWiki)
[15:52:23] <lens0021>	 I think the Zeroconf parsoid is not yet perfect, there is a list of issue already repoted in https://phabricator.wikimedia.org/T266971
[15:53:40] <Frorayz>	 Is there any way to see that actual error? Nginx isn't providing me with any good logs
[15:53:51] <Vulpix>	 You have to be very lucky to get it working with zeroconf :)
[15:54:15] <AntiComposite>	 I'd suspect it might be related to the also-semi-recently-reported https://phabricator.wikimedia.org/T279039
[15:54:24] <Frorayz>	 https://wiki.frorayz.tech/index.php?title=Main_Page&veaction=edit
[15:54:27] <Frorayz>	 My wiki is there
[15:54:55] <Vulpix>	 Maybe the error message is present in the response that contains the error. Try inspecting network requests with the development console of your browser (usually you can open it hitting F12)
[15:55:25] <AntiComposite>	 code	"apierror-visualeditor-docserver-http"
[15:56:28] <AntiComposite>	 the actual request has a 200 code, but that response is just a 400 in a JSON blob
[15:56:47] <Frorayz>	 mediawiki-api-error
[15:56:47] <Frorayz>	 	apierror-visualeditor-docserver-http
[15:56:52] <Frorayz>	 yea I just peeped that
[15:57:06] <Frorayz>	 What is that error is even about
[15:57:39] <Vulpix>	 sometimes you need to explicitly include the wfLoadExtension line as explained here:  https://www.mediawiki.org/wiki/Parsoid#Installation
[15:59:38] <Frorayz>	 Vulpix But I am using 1.36?
[16:00:48] <Vulpix>	 Do you expect that page to be updated? :P
[16:01:07] <Frorayz>	 What do you mean?
[16:01:55] <lens0021>	 I see that https://wiki.frorayz.tech/rest.php/wiki.frorayz.tech/v3/page/html/Main%20Page is redirected to a non existing page
[16:02:12] <Vulpix>	 You should just try to add that line and see if it fixes your problem. If not, explore other options. A one-line addition is something easy to add
[16:02:57] <AntiComposite>	 hrm, did you change $wgScriptPath ?
[16:03:31] <Frorayz>	 I did but same lol
[16:03:43] <Frorayz>	 and no I didn't touch $wgScriptPath
[16:03:47] <lens0021>	 Special:Version shows 	/rest.php as rest.php's entry point
[16:03:49] <Vulpix>	 It looks like bad rewrite rules
[16:05:32] <Frorayz>	 https://pastebin.com/i36JkLfu
[16:05:38] <Frorayz>	 My nginx conf for that wiki
[16:05:52] <Frorayz>	 Can anyone shed light there if its bad rewrite 
[16:06:04] <Frorayz>	 lens0021 wdym?
[16:07:03] <Vulpix>	 Yes, it's bad rewrite
[16:07:40] <Vulpix>	 Have you tried https://www.mediawiki.org/wiki/Manual:Short_URL/Nginx ? Your rules looks like playing whack-a-mole to close the load of unwanted files from the server
[16:08:03] <lens0021>	 Frorayz: the url I sent must show a main page, if configuration is correct
[16:08:42] <lens0021>	 s/a main page/the main page/
[16:08:50] <Frorayz>	  maybe its a bad rewrite
[16:08:56] <Frorayz>	 lemme chage the nginx conf to that
[16:17:16] <AntiComposite>	 Frorayz, any changes?
[16:18:27] <Frorayz>	 AntiComposite everything is broken lol
[16:19:08] <Frorayz>	 Yea idk what hapapned here
[16:19:41] <AntiComposite>	 something's still messed up with your script path
[16:20:08] <AntiComposite>	 https://wiki.frorayz.tech/index.php?title=Main_Page should be wiki.frorayz.tech/w/index.php...
[16:20:52] <Frorayz>	 I just followed whatever Vulpix linked me
[16:21:04] <Frorayz>	 my scrippath is this
[16:21:11] <Frorayz>	 $wgScriptPath = "/w";
[16:21:18] <Frorayz>	 $wgArticlePath = "/wiki/$1";
[16:21:18] <Frorayz>	 $wgUsePathInfo = true;
[16:21:20] <Frorayz>	 those too
[16:21:52] <AntiComposite>	 yes, mediawiki is expecting things in /w/, but nginx is serving them from /
[16:22:39] <Vulpix>	 You can change that. Having the wiki on a subdirectory is not mandatory
[16:23:16] <Vulpix>	 Just remove the /w from everywhere in nginx config. It should work
[16:24:46] <Frorayz>	 change scriptpath to blank then?
[16:29:57] <Frorayz>	 thank you Vulpix
[16:30:02] <Frorayz>	 I fixed it by using this config
[16:30:14] <Vulpix>	 good!
[16:30:17] <Frorayz>	 https://wiki.archlinux.org/title/MediaWiki
[16:30:21] <Frorayz>	 it was rewrite
[16:30:38] <Frorayz>	 man i spent the whole day on this lol
[17:26:16] <ShakespeareFan00>	 hi
[17:26:21] <ShakespeareFan00>	 Anyone around?
[17:26:32] <ShakespeareFan00>	 I'd like someone to check something
[17:26:51] <ShakespeareFan00>	 https://en.wikisource.org/wiki/Template:LR_sidenote/sandbox
[17:27:05] <ShakespeareFan00>	 The expected and Actual output should be identical
[17:27:25] <ShakespeareFan00>	 but they aren'thttps://en.wikisource.org/wiki/Template:LR_sidenote/testcases
[17:27:48] <ShakespeareFan00>	 This is despite all that the template is doing is passing on paramaters if they exist
[17:27:55] <ShakespeareFan00>	 I'm very confused
[18:07:19] <lens0021>	 ShakespeareFan00: i haven't tested and not sure this is related but `{{#if:{{{var}}}|something}}`s should be `{{#if:{{{var|}}}|something}}`
[18:10:47] <lens0021>	 `{{{var}}}` would remain even if the var is not given, therefore `{{#if:{{{var}}}|true|false}}` is always true
[18:44:05] <lens0021>	  ShakespeareFan00: could you try to replace `{{#if:{{{align}}}|align={{{align}}}}}` with `|align={{{align|}}}`? i think the 'if' parser functions are unnecessary
[18:46:41] <ShakespeareFan00>	 lens0021 Already implemented
[18:46:49] <ShakespeareFan00>	 :)
[20:49:22] <ShakespeareFan00>	 And I ended up reverting everything as it completely broke :(
[20:49:30] <ShakespeareFan00>	 due to something else