This is a tracker task to figure out testing / qa needs and any work / changes needed to VisualEditor to switchover from Parsoid/JS to Parsoid/PHP.
T229015: Tracking: Direct live production traffic at Parsoid/PHP is the tracker task for deployment. But, we don't anticipate a deploy before mid-September 2019 at this time. But, let us handle this as if we are going to be deploying around mid to end September.
Since VE talks to RESTBase, there is nothing that will change on that end. However, T229025: Add ability to RESTBase to partition client traffic to Parsoid/PHP and T229018: RESTBase should be able to store Parsoid/PHP contents in Cassandra alongwith Parsoid/JS contents implies that VE might have to handle cookies tracking which version of Parsoid generated its HTML unless we come with a mechanism for handling it in RESTBase / Parsoid that is transparent to clients. But, for now, it is probably safe to assume that VE might need to handle a cookie related to this.
We will also do an early deployment to the beta cluster so that clients can do early testing there. But, please comment on the ticket / edit the description adding any other requirements to ensure we cover all our bases.
Using Parsoid/PHP with VE
In order to test Parsoid/PHP output and transformations, the client (VE) needs to send the X-Parsoid-Variant: php header with the request. This needs to be done consistently for the same domain, i.e. all VE -> RB requests (both GETs and POSTs) need to contain the header for the domain in question (one can go on a per-session basis as well but this is prone to errors). An important thing to note here: this means that even initial GET requests need to be made explicitly with the header. This means that VE cannot use preloaded content for such edits, as it will result in a 404 from RESTBase during transforms.