Last modified: 2014-07-14 16:33:51 UTC
From English Wikipedia: I've not yet done a lot with refs and reflists (a lot of my work is stub-sorting where it rarely crops up) but.... Editing Howard Wilson Elementary School I changed the number of columns of {{reflist}} from 2 to 1 (there's only one ref and it looks daft over 2 cols). The whole reflist disappeared, while I stayed in VE - see edit summary. On saving the page, it was there all present and correct. This is one of several instances where VE alarms the editor: if it's supposed to be a Visual Editor, it needs to reflect changes made and not give the impression that the template has been deleted. Worrying enough for an experienced editor - totally offputting for someone new. Apologies if this exact problem, or a more generalised case, is already tracked. PamD 16:38, 9 July 2013 (UTC)
Confirmed. This one's especially annoying given how common {{reflist}} is. See also bug 50075 (which I was no longer able to reproduce).
This will be fixed when we switch over to Parsoid rendering the templates mid-edit rather than rely on PHP parser.
*** Bug 67856 has been marked as a duplicate of this bug. ***
(In reply to James Forrester from comment #2) > This will be fixed when we switch over to Parsoid rendering the templates > mid-edit rather than rely on PHP parser. As follow-up, right now we don't have a way to give context to Parsoid, so when parsing a template that generates part of a wider structure – e.g. a cell, row or section of a table – we just give the template itself, contextless. This means that Parsoid (correctly) returns a fostered-out block, which we (correctly) splice into the location, meaning the document looks very odd. However, it saves fine. In the future we'd need a way to tell Parsoid that "this is an update to transclusion id=1234 in structure id=4321" or something so Parsoid has context; I assume this will need to wait until Parsoid puts GUIDs into the source for us.
