[00:00:47] Reedy would you also be able to merge https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Flow/+/560434/ please? :) [00:02:52] Reedy <3 [00:04:35] Reedy i think we need https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Flow/+/560438/ [00:04:39] as tests are failing [00:04:49] https://integration.wikimedia.org/ci/job/mwgate-node10-docker/68825/console [13:43:21] Up now... [15:05:52] I think related to the openstack upgrade? [15:42:29] yea, probably [19:15:32] Hi, I am trying to debug Parsoid extension code called through Nginx/core using xdebug with PhpStorm. I can run PHP scripts and xdebug them fine, but not extension code through Nginx/core as the breakpoints never hit when using a PHP HTTP Request (PhpStorm configuration). Does anyone in core use PhpStorm as their IDE with xdebug? I assume there is some configuration info I am missing somewhere, but my research [19:15:32] on topic has not yielded a fix. [19:17:50] https://www.mediawiki.org/wiki/Manual:How_to_debug/with_MediaWiki-Vagrant_and_PHPStorm is about all I've ever seen, but I've no idea if extension worked [19:17:55] Gergo did write it [19:30:08] Thanks, will give it a shot :-) [19:32:08] The JetBrains people are pretty good with support... [19:32:25] On numerous occasions they've cloned mediawiki and 800+ extensions to reproduce perf bugs I've reported :) [19:39:31] Good to know JetBrains might be able to help :-) [20:46:09] sbailey: logs go to /vagrant/logs/xdebug.log, that can show whether the problem is with connecting back to PhpStorm (could be a port conflict for example), or debugging is not even initiated in the first place (so something is wrong with the cookie / env var that should trigger it, or xdebug is not correctly installed in the first place) [20:48:30] one thing to note that if control is passed via internal HTTP calls (like core calling the parsoid API), that won't work since the cookie / env does not get forwarded [20:48:59] you'd have to hack around that, or change xdebug to always-active mode [21:27:34] tgr, thanks for the advice. I can catch index.php with a breakpoint now, but not rest.php. I know my URL to the rest.php is working and if I break rest.php, it dies, so a bit of a mystery about why rest.php breakpoints don't work. Getting all the way to Parsoid through the extension I can imagine is going to require more effort and might not be possible. [21:28:20] are you calling rest.php manually, from the browser? or is called from MediaWiki? [21:29:27] Actually it is being called by PhpStorm using a configuration. I can use that to get index.php to run MediaWiki so rest.php ought to be similar. [21:30:24] using a URL "PHP HTTP Request" provided by PhpStorm [21:30:50] IMO it's a lot easier to do manual calls and avoid using the debug mode of PHPStorm [21:31:20] as in, there is a "Debug" option and a separate "Start listening for PHP connections" which assumes you initiate the connection manually [21:31:35] the first I found not really helpful for debugging PHP [21:32:30] LOL, I am not familiar with doing what you just said. Agree PHP debugging is of limited value and only useful in certain cases. [21:34:50] you set the breakpoints, make sure "Start listening for PHP connections" is on, and initate the request with the php xdebug cookie (there's a browser extension) or env variable (vagrant has xdebug_on / xdebug_off commands to export / unexport it) [21:35:48] xdebug connects back to some predefined port on your host machine, phpstorm detects it and goes into debugging mode [21:37:02] I think the "Debug" button would do mostly the same thing internally, except that PHPStorm does the initial request for you (so instead of clicking on a browser extension icon you have to configure a PHPstorm test profile, that's the not really helpful part) [21:40:24] https://xdebug.org/docs/remote has links to the extensions, and also info on how to set the cookie / env variable / GET parameter manually if you prefer that (e.g. testing via curl)