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 switching over Flow to Parsoid/PHP around end September / early October. Since Flow does not talk to RESTBase, Flow would need a config change to update its endpoints. At this time, we are planning to switch Parsoid clients one at a time. Currently, we are considering switching over Flow as the last Parsoid client. We are assuming we will have all the bugs ironed out by that time and can do a simple switchover without needing traffic partitioning. But, if it becomes necessary, Flow will need to manage a new cookie. Very importantly, we should chat if Flow's HTML storage has any data-parsoid DSR offsets stored there because they will be invalid when we switch over to Parsoid/PHP. Parsoid/PHP can add some metadata to the header indicating that its provenance so Parsoid/PHP ignores DSR offsets if it didn't have the right metadata. In any case, this is one thing that we should chat about sooner than later. We will also do an early deployment to the beta cluster so that clients can do early testing there. However, Flow will nevertheless need some update / code to pick its endpoint on the Beta cluster. 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 switching over Flow to Parsoid/PHP around end September / early October. Since Flow does not talk to RESTBase, Flow would need a config change to update its endpoints. At this time, we are planning to switch Parsoid clients one at a time. Currently, we are considering switching over Flow as the last Parsoid client. We are assuming we will have all the bugs ironed out by that time and can do a simple switchover without needing traffic partitioning. But, if it becomes necessary, Flow will need to manage a new cookie. While Flow's HTML storage has data-parsoid DSR offsets stored there, since Flow does not use selective serialization, these offsets are ignored by Parsoid. Nevertheless, it might be appropriate to null out the old offsets (or have some suitable protection against future use) since the offsets generated by Parsoid/JS code are invalid in Parsoid/PHP land. We will also do an early deployment to the beta cluster so that clients can do early testing there. However, Flow will nevertheless need some update / code to pick its endpoint on the Beta cluster. 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 switching over Flow to Parsoid/PHP around end September / early October. Since Flow does not talk to RESTBase, Flow would need a config change to update its endpoints. At this time, we are planning to switch Parsoid clients one at a time. Currently, we are considering switching over Flow as the last Parsoid client. We are assuming we will have all the bugs ironed out by that time and can do a simple switchover without needing traffic partitioning. But, if it becomes necessary, Flow will need to manage a new cookie. Very importantlyWhile Flow's HTML storage has data-parsoid DSR offsets stored there, we should chat if Flow's HTML storage has any data-parsoid DSR offsets stored there because they will be invalid when we switch over to Parsoid/PHP.since Flow does not use selective serialization, Parsoid/PHP can add some metadata to the header indicating that its provenance so Parsoid/PHP ignores DSR offsets if it didn't have the right metadatathese offsets are ignored by Parsoid. In any caseNevertheless, this is one thing that we should chat about sooner than laterit might be appropriate to null out the old offsets (or have some suitable protection against future use) since the offsets generated by Parsoid/JS code are invalid in Parsoid/PHP land. We will also do an early deployment to the beta cluster so that clients can do early testing there. However, Flow will nevertheless need some update / code to pick its endpoint on the Beta cluster. But, please comment on the ticket / edit the description adding any other requirements to ensure we cover all our bases.