Change Details

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} 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 CX talks to RESTBase, there is nothing that will change on that end. However, {T229025} and {T229018} implies that CX 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 CX 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.

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} 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 CX talks to RESTBase, there is nothing that will change on that end. However, {T229025} and {T229018} implies that CX 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 CX 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 (Note copied from T229074) == 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.

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} 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 CX talks to RESTBase, there is nothing that will change on that end. However, {T229025} and {T229018} implies that CX 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 CX 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 (Note copied from T229074) == 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.