Page MenuHomePhabricator

mw.title.getCurrentTitle():getContent() is undef when creating new page in VE preview
Closed, InvalidPublic

Description

A recent change to Module:Citation/CS1 is causing errors when using citoid when creating a new page.

Details here:

https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1#Broken_citation_module

Event Timeline

Esanders subscribed.

Could be a Parsoid <> Lua interaction? I think {{PAGENAME}] works fine when rendering those templates, so the title is definitely being passed to Parsoid.

Hang on, the method is getting the full wikitext content of the page. It's probably expected that it returns null when the page doesn't exist.

On-wiki issue with Lua module. Fixed there.

Not sure I believe that. In the simple create-a-new-article-with-the-wikisource-editor test that I described at Help talk:Citation Style 1, I did not save anything so the preview cannot be, as you claim in that discussion, "against the last saved version of the page" (there is no saved version of a page that has never been saved). I agree that Module:Citation/CS1/Configuration should probably handle a case where mw.title.getCurrentTitle():getContent() returns nil but I do not agree that your proposal to do so is the right and proper remedy of the ve-can't-properly-render-a-preview problem. Clearly because it is possible to preview a never-saved page created by the wikisource editor, the root fault does not lie with ~/Configuration.

(there is no saved version of a page that has never been saved)

This is precisely the problem. To preview a page in the classic wikitext editor you have to post the entire wikitext of the article, so that information is available on the server for the Lua module to get from getCurrentTitle():getContent(). In VE+Citoid the full document is not sent to create a preview, we just send the snippet we need to render which is much faster.

Accordingly it is possible and valid for a tool to want to generate a rendering of a citation without having to provide the full wikitext context, so the module should be written to work even when getContent returns nil.

Are you saying that what editors see while editing, is a facsimile and not a true preview of the article? It would seem so. When changes are made, ve only only tweaks those pixels that have been changed? Is that why the {{use xxx dates}} templates appear as puzzle pieces – just visual indicators that some non-displaying something is here? So anything that doesn't render directly onto the 'canvas' doesn't preview (except as a puzzle piece). For example {{italic title}} when added via ve, does not italicize the article title, does not render the expected MediaWiki error message when {{italic title}} conflicts with a {{DISPLAYTITLE}} setting that occurs earlier in the page – things we would expect from a true preview. To learn of this kind of error, editors must either shift to the wikisource editor and preview from there or save the page. There is no true preview in ve.

The same will be true if editors add {{use dmy dates}} or {{use mdy dates}} or replace the one with the other; no visible change to the article page until the document is saved.

For a new document, ve paints the canvas from scratch; new {{use xxx dates}} and cs1|2 templates that should preview correctly don't because ve doesn't preview. This Lua error occurred because there is no old version of the new doc. For an old document, ve renders everything once at the start but those things that require the new doc (changed {{use xxx dates}}) don't display as expected (from the editor's point of view) because ve doesn't preview. This lua error doesn't occur for new edits to old docs because there is an old doc; the new edits just display wrongly until saved or previewed via the wikisource editor. Do I have that right?

Yes, VE edits a representation of the document that is is not fully re-rendered by the parser until it is saved.