[01:06:11] <k-man>	 i recently moved my mediawiki instance to a vps (it was hosted internaly before). it's mostly working fine but i'm getting fairly frequent parsoid timeouts when trying to edit a page or save a page after edit
[01:07:09] <k-man>	 any idea how to diagnose what the issue is?
[07:25:19] <Remilia>	 k-man: which MW version are you running by the way?
[12:58:58] <Jhs>	 Hi folks! I'm having a problem with VisualEditor in a wiki i'm maintaining. It works fine most of the time, except when you try to edit pages that have rather large tables in them. Then you get an "Error contacting the Parsoid/RESTBase server (HTTP 500)". Any idea what the cause (and more importantly, fix) is?
[12:59:42] <Jhs>	 ping tgr|away who i saw answering a similar question in StackOverflow :)
[13:01:50] <Vulpix>	 Jhs: you may be hitting PHP's memory_limit setting
[13:02:39] <Jhs>	 yeah, i tried adding ini_set( 'memory_limit', '1400M' ); (which is the same as Wikimedia uses) to LocalSettings.php, but it had no effect (but that may be the wrong way to do it? idk)
[13:02:48] <Jhs>	 the normal memory_limit is 512M
[13:04:17] <Vulpix>	 If you've set php error_log to log errors to a file, it should list there a descriptive error message if it crashes because of memory or other fatal condition
[13:06:52] <Jhs>	 aight, i'll check it out… it's all made more complicated by me not having direct access to the server, so i have to go through someone else to check those kinds of things (or install packages or w/e), but luckily he's a pretty responsive guy :)
[14:22:16] <akoopal>	 anybody experience in getting VE/parsoid working under docker?
[14:24:33] <rundg[m]>	 akoopal: Since REL1_35 it just works b/c parsoid is in PHP. There is no service to run.
[14:25:03] <akoopal>	 I know, but docker makes it complicated, it doesn't work.
[14:26:06] <akoopal>	 I have the default dockerhub image, with some extra's, and nginx in front for rewrite for shorturls
[14:26:11] <rundg[m]>	 akoopal: Do you have an error message, or more information on your setup? It works for me.
[14:27:26] <akoopal>	 I tested a lot, sometimes I get an error it can't connect, I now get an empty error box :_(
[14:28:11] <akoopal>	 setup is nginx is redirecting /ssmw2 to the docker container, and /ssmwiki2 to /ssmw2 for the normal shorturl stuff
[14:28:49] <akoopal>	 I had noticed in early tests it tried to reach /ssmw2/rest.php in the mediawiki container
[14:29:53] <akoopal>	 I have configured:
[14:29:58] <akoopal>	 wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );
[14:29:58] <akoopal>	 $wgVirtualRestConfig['modules']['parsoid'] = array( 'url' => $wgServer . $wgScriptPath . '/rest.php',
[14:30:01] <akoopal>	 );
[14:30:29] <akoopal>	 (hmm, didn't paste well)
[14:31:33] <rundg[m]>	 <akoopal> "I have the default dockerhub..." <- I'm guessing that the shorturl rewrites are interferring. I use nginx to simply manage the domain mapping to ports on the host for multiple docker instances. I handle my ShortURLS in .htaccess in each container / MediaWiki instance
[14:33:24] <akoopal>	 hmm, everything for that is working just not VE
[14:34:19] <akoopal>	 but the docker image is running on /
[14:35:09] <akoopal>	 so difficult to do the rewrites there?
[14:37:03] <rundg[m]>	 I would try commenting out the whole `wgVirtualRestConfig` (use the default) I don't set that anywhere in my setup.
[14:39:40] <akoopal>	 I started without, I found somewhere to do it like this
[14:40:35] <rundg[m]>	 similarly, you don't need to `wfLoadExtension('Parsoid')`, unless you are a developer https://www.mediawiki.org/wiki/Parsoid#Installation
[14:41:26] <akoopal>	 yeah, I understood you need to load it if you get the config
[14:46:23] <akoopal>	 rundg[m]: are you using the docker-hub image?
[14:47:56] <rundg[m]>	 You can test your parsoid configuration by visiting... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/746efa989a41027f160f6450779c3217dc3f1853)
[14:48:31] <rundg[m]>	 akoopal: I'm using it as the base for my custom image.
[14:53:42] <akoopal>	 hmm, with eval.php I see
[14:53:46] <akoopal>	 https://wwwint.emea.vzbi.com
[14:53:49] <akoopal>	 I get
[14:53:59] <akoopal>	 {"messageTranslations":{"en":"The requested path (/rest.php/wwwint.emea.vzbi.com/v3/page/html/Main%20Page) was not inside the REST API root path (/ssmw2/rest.php)"},"httpCode":404,"httpReason":"Not Found"}
[14:59:15] <akoopal>	 same error if I comment out the load and setting of the config
[15:08:57] <akoopal>	 hmm, and I tried the nginx config you suggested, doesnt' help
[17:43:39] <tgr>	 akoopal: what is your script path?
[18:03:23] <akoopal>	 tgr: /ssmw2
[18:08:39] <Platonides>	 akoopal: it just works for me
[18:08:59] <Platonides>	 but I'm not doing url rewrites in front of mediawiki
[18:09:19] <akoopal>	 not using pretty url's?
[18:09:39] <akoopal>	 short url's I mean
[18:09:43] <Platonides>	 not doing that in front of mediawiki
[18:09:54] <akoopal>	 so doing it in the container
[18:10:21] <Platonides>	 yes
[18:10:37] <akoopal>	 will spend some time next week to redo it then.
[18:10:48] <akoopal>	 it is work, and workweek is over :-)
[18:11:00] <Platonides>	 the proxy simply sends it with the same path
[18:11:22] <Platonides>	 that's easier since you don't need to teach MediaWiki to provide links to somewhere else than where it feels to be
[18:11:49] <tgr>	 akoopal: what is $wgRestPath set to?
[18:13:04] <akoopal>	 not setting it myself, let me look
[18:15:01] <akoopal>	  /ssmw2/rest.php
[18:17:56] <tgr>	 so apparently you are rewriting URLs in such a way that MediaWiki doesn't see the /ssmw2 prefix anymore, and rest.php has a security check (I guess?) where it disallows URLs which do not match the expected prefix
[18:18:36] <akoopal>	 the rewrites are now in the ngnix container, the mediawikicontainer everything is in /
[18:19:12] <akoopal>	 so it seems that was a bad idea and I need to bring the rewrites in the mediawiki container indeed
[18:19:43] <akoopal>	 thanks for confirming, to redesign then
[18:21:06] <tgr>	 you could change $wgRestPath and it would probably work. But not doing it in the first place is certainly the better approach.
[18:24:58] <akoopal>	 I could just try first, but better to move the rewrites. Will try it, but as I said, after the weekend. Difficult to test from my private laptop, and switch the worklaptop of in the weekend