Last modified: 2013-09-18 23:01:29 UTC
I updated Flow, Parsoid, and VisualEditor on toro. Adding a new post worked fine and brought up VE (after a long delay during which the text area should probably be locked) and I could WYSIWYG. \o/ But existing summary and some posts on http://toro.wmflabs.org/wiki/Special:Flow/Sandbox_2 that have images and links in them show stuff like <a rel="mw:WikiLink" href=".//Subpage" data-parsoid="{"stx":"simple","a":{"href":".//Subpage"},"sa":{"href":"/Subpage"},"dsr":[89,101,2,2]}"> suggesting Flow is having problems figuring out Parsoid HTML content. I had set $wgFlowUseParsoid=true, now I think obsolete. I tried setting $wgFlowContentFormat='html', didn't seem to change behavior. Firebug reported some XHR errors, possibly from some VE API call, but now not. If the issue is existing content doesn't render right, this is fine to mark WONTFIX. We haven't promised data compatibility yet.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/185
This is due to us previously not tracking what kind of content was stored in the field. We now store a value of either 'html' or 'wikitext' in the content flags of the revision. Not highly efficient, but the following query would fix the issue: UPDATE flow_revision set rev_flags = CONCAT(rev_flags, ',html' ) WHERE rev_flags NOT LIKE '%html%' and rev_flags NOT LIKE '%wikitext%'; Untested, but should work. Not sure if its worthwhile to build out the proper maintenance script to migrate.
(In reply to comment #2) > This is due to us previously not tracking what kind of content was stored in > the field. Yup, flow_revision rev_flags had just 'utf-8'. > UPDATE flow_revision set rev_flags = CONCAT(rev_flags, ',html' ) WHERE > rev_flags NOT LIKE '%html%' and rev_flags NOT LIKE '%wikitext%'; It worked! (now Toro has other errors...)
