Update Wikibase to use Secondary Data Update mechanism
Open, Needs TriagePublic
Actions

Description

My apologies for a vague task description; hopefully we can refine this as folks with more understanding of MCR and/or Wikibase look at the task.

My understanding based on conversations at Wikimania is that Wikibase currently uses a mechanism closely tied to the legacy parser in order to transfer entity usage data from ParserOutput extensionData to a database where it can be used to trigger purges of articles when used wikibase entities are changed.

Broadly speaking, this should probably be changed to use the secondary data update mechanism introduced (I believe) in MCR in order to decouple this database update from the legacy parser. This will allow use to fully replace the legacy parser with parsoid for metadata update: T393716: [EPIC] RefreshLinksJob should use Parsoid-generated metadata.

Related Objects
Search...

Status	Subtype	Assigned	Task
Open	Release	None	T84936 Release VisualEditor-MediaWiki as "1.0"
Open		None	T50429 [Epic] Support editing parts of a page in VisualEditor-MediaWiki
Open		None	T54365 Explore performance gains from progressive (JIT?) de-alienation in VisualEditor
Open		None	T396539 Introduce a way to edit a span of text from within read mode
Open		None	T385558 Improve copy and paste from read mode to VE
Open		None	T174303 Copy-pasting linked ISBN numbers from view mode HTML into VisualEditor inserts wikitext links to Special:BookSources (it should turn them into magic links?)
Open	Feature	None	T54091 The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces
Open		None	T55784 [EPIC] Use Parsoid HTML for all page views
Open		None	T272987 [EPIC] Parsoid read views for DiscussionTools
Open		None	T297840 Populate ParserCache with Parsoid output as a post-edit hook
Open		None	T393717 Put lints in ParserOutput/RefreshLinksJob
Open	BUG REPORT	None	T393682 Wikifunctions fragments that trigger errors and try to put the page in a tracking category show it at the bottom of the view page, but the pages using the fragment do not appear on the category page
Open		None	T409815 SLI: MediaWiki system load
Open		None	T393716 [EPIC] RefreshLinksJob should use Parsoid-generated metadata
Open		None	T310511 Metadata comparison testing between Parsoid and the legacy parser
Open		None	T310512 Parsoid and the legacy parser should emit exactly the same ParserOutput metadata
Open		None	T402371 Client pages of Wikidata should be able to track their usage of WD data using Parsoid
Open		None	T403902 Update Wikibase to use Secondary Data Update mechanism
Open		None	T331483 Resolve differences between Parsoid & legacy parser TOC metadata output for template, extension, and parser-function generated content
Resolved		cscott	T213468 Parsoid section IDs don't correspond to PHP section IDs when headings are transcluded
Resolved		ABreault-WMF	T215628 Make Parsoid and PHP edit-section numbering consistent when <noinclude> and <includeonly> are in use
Resolved		cscott	T214538 MediaWiki shouldn't assign section numbers during tokenization, but instead only when headings are generated
Open		cscott	T359221 Parsoid's TOC handling needs to deal with HTML-returning components (exts, SPTs, parser funcs returning HTML) consistently
Resolved		ssastry	T359450 Parsoid is not adding headings to TOC entries in some templated content scenarios
Resolved		Jgiannelos	T402456 More Parsoid TOC edge cases?
Open		Jgiannelos	T415554 From TOC difftesting (legacy/parsoid): Differences in template handling from sections
Open		Jgiannelos	T415558 From TOC difftesting (legacy/parsoid): Mismatch when sections come from the same article
Open		Jgiannelos	T415563 From TOC difftesting (legacy/parsoid): Inconsistent index level between legacy and parsoid
Open		Jgiannelos	T415565 From TOC difftesting (legacy/parsoid): Section titles wrapped in html elements on parsoid
Resolved		Jgiannelos	T403188 Implement TOC comparison in Linter extension