Page MenuHomePhabricator

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

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.

Event Timeline

Quiddity created this task.Feb 23 2015, 5:31 PM
Quiddity updated the task description. (Show Details)
Quiddity raised the priority of this task from to Needs Triage.
Quiddity added a subscriber: Quiddity.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 23 2015, 5:31 PM
EBernhardson triaged this task as Unbreak Now! priority.Feb 23 2015, 6:40 PM
EBernhardson added a subscriber: EBernhardson.

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.

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

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

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

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

Cherry picked to 1.25wmf19 and 1.25wmf20, will be deployed today in evening SWAT

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

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

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

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

EBernhardson closed this task as Resolved.Mar 10 2015, 11:26 PM

This has been deployed to wmf19 and wmf20 now