Lucas_Werkmeister_WMDE added a comment.
Well, I was more worried that a non-`forcelinkupdate` purge might not update the parser cache. But as far as I can tell: - A regular purge //invalidates// the parser cache. The page will be re-parsed the next time it is requested. (Code can still get the cached parser output via `ParserCache::getDirty()`. `RefreshLinksJob` uses this and is happy to use a dirty output as long as its timestamp is recent enough.) This is also what `?action=purge` does. - A purge with `forcelinkupdate` immediately //updates// the parser cache, and then performs “secondary data updates”, including but not limited to a `LinksUpdate`. `Content` and `ContentHandler` instances can register any other updates they want here, and the `AbstractContent` implementation further delegates this to the `SecondaryDataUpdates` hook <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Hooks/SecondaryDataUpdates>. - A purge with `forcerecursivelinkupdate` does the same thing, but sets the flag `$recursive = true` for the secondary data updates. For `LinksUpdate`, this means to enqueue jobs for other pages linking to the linked-to pages (those jobs are in turn also recursive). The flag is also passed into the now-deprecated `Content::getSecondaryDataUpdates()` (and the aforementioned hook), but not into its replacement `ContentHandler::getSecondaryDataUpdates()`. A regular purge might be enough for us, but that just means that we’ll wait for the parser on the page reload, whereas with `forcelinkupdate` the parse happens while we’re still showing the dialog – I think that would be better for the user. I’m also uneasy about `RefreshLinksJob` using `ParserCache::getDirty()`. TASK DETAIL https://phabricator.wikimedia.org/T227758 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Michael, aaron, Lucas_Werkmeister_WMDE, Addshore, Pablo-WMDE, Aklapper, Lydia_Pintscher, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
