Change Details

Switching to RESTBase makes sense if it allows us to solve the problems we're having with ExternalStore, such as: * No way to update the rendering of a header on move without a null edit * {T59991} RESTBase has a [PHP extension](https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FRestBaseUpdateJobs.git) that listens to updates and automatically tells Parsoid to regenerate the HTML and store the updated version in RESTBase. We would want these to also take into templatelinks, etc. dependencies for Flow. Flow might need to hook in somehow to tell it how our data model works.

Switching to RESTBase makes sense if it allows us to solve the problems we're having with ExternalStore, such as: * No way to update the rendering of a header on move without a null edit * {T59991} RESTBase has a [PHP extension](https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FRestBaseUpdateJobs.git) that listens to updates and automatically tells Parsoid to regenerate the HTML and store the updated version in RESTBase. We would want these to also take into templatelinks, etc. dependencies for Flow. Flow might need to hook in somehow to tell it how our data model works. --- See {T125857} for the canonical task about the actual problem here.

Switching to RESTBase makes sense if it allows us to solve the problems we're having with ExternalStore, such as: * No way to update the rendering of a header on move without a null edit * {T59991} RESTBase has a [PHP extension](https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FRestBaseUpdateJobs.git) that listens to updates and automatically tells Parsoid to regenerate the HTML and store the updated version in RESTBase. We would want these to also take into templatelinks, etc. dependencies for Flow. Flow might need to hook in somehow to tell it how our data model works. --- See {T125857} for the canonical task about the actual problem here.