First reported on mw:Parsoid/Feedback.
As part of the task, let us revisit the following:
- should we change the limits to something a bit higher?
- can we ensure that the top N images are rendered vs. some N images on the page?
- Per @stjn, is there a better UX for flagging these limits to the user (instead of incorrectly rendering them as red links)?
Plan of action
- Bump the limit while keeping it low enough to avoid timeouts
- Make a pageInfo request to determine blue links since this is lighter weight than the fileInfo requests
- https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1315966
- This step also needs to be taken into acount within "Move limiting from AddMediaInfo to the token transform stage"
- Optimize fileInfo request to use findFile instead of findFiles since the performance bottleneck seems to be the gallery extension making single requests per line
- Move limiting from AddMediaInfo to the token transform stage to preserve ordering (otherwise, accumulated tokens will be processed after extension tokens or other tokens creating subpipelines to dom)
- Add a tracking category for pages hitting the limit (note: this might require waiting until Parsoid is used for page metadata)
- Make ParsoidExtensionAPI::renderMedia take a list of files to render to take advantage of batching, to be used by the gallery extension