https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902203 will go out with next week's train. We waited a month to merge it so that parserCache will have rolled over for legacy output read views.
However, the styling also affects Parsoid content. The necessary class was added to Parsoid's output a few weeks ago and is present in content version 2.7.1
RESTBase meanwhile still has older versions of content in storage. This means that if a user tries to edit a page in VE and gets an older version, the styling of media won't be presented correctly. There won't be any problem with editing though, since that was made compatible.
We can revert the patch until a solution is in place but there are few follow on patches that make the task a little more hairy, though not unfeasible.
We have a few options to deal with this though,
- Purge content from RESTBase that's older than the 2.7.1 deploy date. There's a script that can be adapted for that in T296425 but that's never been tried before.
- We can bump the version of content that VE requests so that it should never be returned an older version from storage. The only problem with that is that RESTBase ignores the patch version (the 1 in 2.7.1) and only considers major and minor versions of the accept header when doing semver caret semantics. To account for that, Parsoid has been bumped to 2.8.0 which will also go out in next week's train. But that presents two more problems,
- If the VE patch goes out in the same train as the vendor patch that has the parsoid bump, storage isn't going to be very warm with 2.8.0 content so editors will pay the price of parsing
- The refactored Parsoid http api in core might return old 2.7.1 in parserCache to RESTBase for 2.8.0 requests. This is noted in T333606 and may (or may not) cause RESTBase to reject it as not satisfying the request and error out. This still needs to be verified.