Page MenuHomePhabricator

Parsoid development setup
Closed, ResolvedPublic


T221174 and T221175 require modifying REST API code within Parsoid. I have not previously worked on either Parsoid or REST API. So I need to set up an appropriate environment and be prepared to test my changes. This task exists to track and document that work.

Event Timeline

BPirkle created this task.Aug 6 2019, 2:22 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 6 2019, 2:22 PM
BPirkle added a subscriber: Tgr.Aug 7 2019, 3:04 PM

Per advice from @Tgr , I have:

  1. created a new MediaWiki vagrant box (
  2. enabled the parsoid role
    1. vagrant roles enable parsoid
    2. vagrant provision
  3. navigated to <vagrant root>/srv/parsoid and run "composer install"
    1. on macOS Mohave I had to update my php version to 7.2 via homebrew for this to execute happily
  4. created file <vagrant root>/settings.d/10-Parsoid.php with contents:
if ( file_exists( '/vagrant/srv/parsoid/extension.json' ) ) {
    wfLoadExtension( 'Parsoid', '/vagrant/srv/parsoid/extension.json' );

I can now successfully hit urls like: http://localhost:8080/w/rest.php/localhost/v3/page/text/Main_Page/2 to hit the new REST API and invoke the new handler code from

Note One: a convenient command line way to verify functionality is "curl http://localhost:8080/w/rest.php/user/test/hello"

Note Two: parsoid code is also available via "git clone"

Tgr added a comment.Aug 7 2019, 3:51 PM

(FWIW, you can get into the box with vagrant ssh and run composer there to avoid having to mess with your system config.)

Tested and confirmed on a fresh vagrant box, change merged.

I've now also set up xdebug/PhpStorm. One challenge was base os contention for port 9000. I solved this by reconfiguring debugging to use port 9002.

I'll describe this briefly for anyone who may come across this task. Skipping some details, xdebug (in this context) works like this:

  1. you load a page in your browser running on the base os (in my case, macOS). The request includes includes a cookie indicating that debugging should be active (there are convenient extensions for most browsers that enable this cookie)
  2. the virtual box receives the request, sees the cookie and xdebug (running on the virtual box) sends a debugging request back out to the base os. By default, this request is sent on port 9000.
  3. the IDE (PhpStorm in my case) listens for incoming debugging requests (again by default, on port 9000). On receiving one, it initiates a debugging session.

My problem was that something (php-fpm) was already listening on port 9000, so PhpStorm did not receive the requests. So debugging silently failed. I could probably have reconfigured php-fpm, but at this point I was already pretty deep into xdebug configuration so I decided to reconfigure xdebug instead. I took the following steps:

  1. Added the line "'xdebug.remote_port' => 9002," to the remote debug settings in <vagrant root directory>/puppet/modules/php/manifests/remote_debug.pp.
  2. ran "vagrant provision"
  3. Changed "9000" to "9002" under PhpStorm => Preferences => Languages & Frameworks => PHP => Debug.

Now I'm happily debugging.

Oh, and to figure out what processes were listening on which ports on my Mac, I used:

sudo lsof -iTCP -sTCP:LISTEN -n -P
Tgr added a comment.Aug 22 2019, 3:18 PM

The request includes includes a cookie indicating that debugging should be active (there are convenient extensions for most browsers that enable this cookie)

Vagrant also provides xdebug_on and xdebug_off commands for the CLI (debugging a unit test or maintenance script). (There is a somewhat hard-to-find tutorial about this.)

BPirkle closed this task as Resolved.Sep 4 2019, 12:12 PM