Wikiproject banners at enwiki are subst'd (?) when saved
Closed, ResolvedPublic
Actions

Description

I cannot save {{WikiProject Breakfast|class=project}} as a normal banner in the header-area, anymore. (nor any other WikiProject's banner, eg History). It seems to be getting subst'd or something?
See this edit for example, where I replaced test edit with {{WikiProject History|class=project}} but it saved as this: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow/Developer_test_page&action=compare-header-revisions&header_newRevision=sccu6ohhc74j7vyq

Probably related to T90460: R9. Flow header text-area not expanding when editing because when that table code is in the text-area, it won't auto-expand at all.

Details

Related Changes in Gerrit:

Subject	Repo	Branch	Lines +/-
Store parsoid content exactly as recieved	mediawiki/extensions/Flow	wmf/1.25wmf20	+39 -41
Store parsoid content exactly as recieved	mediawiki/extensions/Flow	wmf/1.25wmf19	+39 -41
Store parsoid content exactly as recieved	mediawiki/extensions/Flow	master	+39 -41

Customize query in gerrit

Related Objects

Mentioned In: rMEXTd5404187bd3c: Updated mediawiki/extensions Project: mediawiki/extensions/Flow…
rEFLWd1ef57054299: Store parsoid content exactly as recieved
rEFLW5ee941378e9a: Store parsoid content exactly as recieved
rEFLWe4ab381fff5d: Store parsoid content exactly as recieved
Mentioned Here: T90460: R9. Flow header text-area not expanding when editing

Event Timeline

Quiddity created this task.Feb 23 2015, 5:31 PM

Quiddity raised the priority of this task from to Needs Triage.

Quiddity updated the task description. (Show Details)

Quiddity added projects: StructuredDiscussions, Collaboration-Team-Triage.

Quiddity subscribed.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 23 2015, 5:31 PM

in a quick test it seems that

Change 192394 had a related patch set uploaded (by EBernhardson):
Store parsoid content exactly as recieved

https://gerrit.wikimedia.org/r/192394

Patch-For-Review

upon investivagation it looks like this is an interaction issue between how flow uses the php DOMDocument and what parsoid expects to be sent. Specifically in my tests it seems just loading the content into DOMDocument and then writing it out unadjusted is enough to trigger this problem.

The easiest fix here is to just not change the HTML content that we send to parsoid to roundtrip. I'll have a patch in today to move the current changes from a pre-save transformation into a pre-render transformation and this should just work again.

There is possibly a deeper bug here too, the DOMDocument output should probably roundtrip, but i have a feeling the issue is more related to us telling DOMDocument to read the content as HTML instead of XML as parsoid would prefer. The reason for this IIRC is because we need to merge in content like the output of Linker::link which is not always valid XML.

EBernhardson claimed this task.Feb 24 2015, 12:33 AM

EBernhardson added a project: Collaboration-Team-Sprint-Q-2015-02-25.

EBernhardson set Security to None.

EBernhardson moved this task from Sprint Q - ends Feb 25 to Code Review on the Collaboration-Team-Sprint-Q-2015-02-25 board.

• DannyH added a project: Collaboration-Team-Sprint-R-2015-03-11.Feb 25 2015, 9:21 PM

• DannyH moved this task from Sprint R - ends March 11 to Code Review Started on the Collaboration-Team-Sprint-R-2015-03-11 board.

Change 192394 merged by jenkins-bot:
Store parsoid content exactly as recieved

https://gerrit.wikimedia.org/r/192394

EBernhardson mentioned this in rEFLWe4ab381fff5d: Store parsoid content exactly as recieved.Mar 6 2015, 4:23 PM

Change 195326 had a related patch set uploaded (by EBernhardson):
Store parsoid content exactly as recieved

https://gerrit.wikimedia.org/r/195326

Change 195327 had a related patch set uploaded (by EBernhardson):
Store parsoid content exactly as recieved