Our testing in T422935 showed that the WikiProjects prototype currently has a measurable performance impact (some 20–40 ms): on every page view it has to load the item and check if it has relevant statements or not. If we proceed with the prototype, we should see if we can eliminate or at least reduce this.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T329284 Make Wikiprojects on Wikidata more visible and accessible | |||
| Open | None | T420907 [WIPR] POC Making WikiProjects for Wikidata links more visible | |||
| Open | None | T428731 [WIPR] Improve performance of WikiProjects sidebar linking |
Event Timeline
Comment Actions
I think what we want to do, broadly speaking, is do the check “does this item have any WikiProject links?” at parse time (when we’ve already loaded the full entity data anyway), store the result in the parser output metadata, and merely move it from there to the sidebar in the SkinBeforeOutput hook. Some Wikibase metadata seems to be available in the hook, at least, at:
$skin->getOutput()->getProperty( 'wikibase-meta-tags' )
(If I recall correctly, there’s a distinction between “extension metadata” at the ParserOutput level and “properties” at the OutputPage level. The skin has an OutputPage, not a ParserOutput, so we’ll need some component that copies the metadata from the one to the other – I believe that’s how the wikibase-meta-tags end up there too.)
This will mean that WikiProject links won’t update until the page is rerendered or purged (both when we initially introduce the config and when we eventually make it wiki-configurable via T423419), but IMHO that’s an acceptable cost we’ll have to bear.