From T119078#1965648: Remove the wbEntity blob on mobile, because it does not allow editing at all.
Related: T125899: Spike: Should the mobile site vary the ParserOutput cache?
Description
Description
Related Objects
Related Objects
- Mentioned Here
- T106099: RFC: Page composition using service workers and server-side JS fall-back
T124356: Incorrect TOC and section edit links rendering in Vector due to ParserCache corruption via ParserOutput::setText( ParserOutput::getText() )
T125899: Spike: Should the mobile site vary the ParserOutput cache?
T119078: [Task] Move wbentity JSON to the end of the HTML
Event Timeline
Comment Actions
@Jdlrobson replied:
Hah! Very timely.
https://phabricator.wikimedia.org/T125899I'm pondering the same question. We are keen to lazy load content (references and images) in the mobile web experience for mediawiki.
So it looks like I was right: mobile uses a separate web cache, but shares a parser cache. That makes it tricky to serve a different representation of the content for mobile. See T125899: Spike: Should the mobile site vary the ParserOutput cache?
Comment Actions
Quick summary of the investigation:
- mobile uses separate web cache keys, so no problem there.
- mobile shares the parser cache with the desktop version
- if we remove the blob from the cached ParserOutput for mobile, we need to split the parser cache. That may be doable, but isn't great, see T125899.
- it would be nicer to never put the serialized entity into the ParserCache, but add it on the fly when serving the editable (desktop) interface.
- We'd need a mechanism for manipulating the ParserOutput when it gets pulled from the ParserCache.
- We may want to cache the serialized blob separately (which means more fun with purging).
- compare T106099: RFC: Page composition using service workers and server-side JS fall-back
Comment Actions
@daniel I think the blob could be added in OutputPage, since it's a JS variable. (we already add other, user-specific JS vars there like wbUserCanEdit and wbUserIsBlocked)
but yes we should have some caching for the blob.
Comment Actions
I suggest to put any data we want to optionally serve into the ParserOutput's extension data slots. That way, the info is cached, but won't get served to the client, unless we explicitly splice it in via an OutputPage hook. We can do the splicing as appropriate for the specific type of client.
We have to be careful though that any distinction we make when constructing the OutputPage from the ParserOutput has to be consistent with how the web cache is split.