Page MenuHomePhabricator

Live preview shows incorrect proofread status
Open, Needs TriagePublicBUG REPORT

Description

Steps to reproduce

  1. Enable Show previews without reloading the page (“live preview”) in your Wikisource preferences (e.g. multilingual Wikisource).
  2. Go to an already proofread page (e.g. Page:Hærramek ja bæsstamek Jesus Kristus ođđa Testament.pdf/520).
  3. Edit the page.
  4. Without any changes, click Preview.

Actual result

  1. The banner says This page has not been proofread.

Expected result

  1. The banner says This page has been proofread (or whatever proofread status the chosen page has).

Event Timeline

According to a German Wikisource thread, the bug is present since 10/14 days, which matches the rollout of c1f80efe05349cc39cb82dc9347b0a7699b11dfd (T304303) on 18 May (11 days ago). Looking at the code, ProofreadPage\Page\PageContentHandler::unserializeContentInWikitext (rEPRP includes/Page/PageContentHandler.php:225-289 (at 0bed1ccf)) depends on the presence of the <noinclude> tags, and exactly those were removed in that patch. I don’t think we can come up with a solution that doesn’t include a bunch of hacks to patch the 2010 and 2006 wikitext editors (unless the live preview is substantially rewritten to natively support editing multiple slots at once), so maybe the easiest solution is to just revert the changes to ext.proofreadpage.page.edit.js.

Indeed, this bug is related to c1f80efe05349cc39cb82dc9347b0a7699b11dfd (T304303): the live preview feature relies on the JS API allowing to fetch the current content of the editing area. To fix T183950 we dropped the hack inside of ProofreadPage that provides not only the page body but also the proofreading level and the page header/footer as page content. So, after this change, only the page body is fed to the live preview feature, hence the bug. A possible solution might be to add back the "complete page content" hack inside of ProofreadPage but some signficant work would be required to make features like find/replace work with this hack.

This bug affects not just the proofread status, which is more cosmetic than anything, but also all other uses of the header and footer, which is a lot more troublesome. Most obviously it means you can't preview any changes to the content in the header/footer (a running header, for example); but it also breaks the use of any page-spanning templates. For example, on enWS Template:TOCstyle generates a table and relies on having {{TOCstyle|header=yes}} in the header so that when invoked in the body with {{TOCstyle|continues=yes}} it can output only a markup fragment. Since the preview doesn't have the header the body ends up being parsed as generic unordered list markup. enWS has a number of templates that operate on this model. And without testing I imagine it also will affect any other page-spanning constructs such as basic table wikimarkup (multipage tables are common in all sorts of works).

That's a pretty major annoyance with significant impact on workflow, and it makes an already complicated solution effectively unmanageable for less experienced or less technically-inclined users. Given search and replace has been broken for half a decade, I'm not sure this is a reasonable tradeoff.

Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality. Page-spanning constructs (e.g. tables, like the tables of contents in just about every book) are now literally impossible to work with when live previews are on, and it is in practice impossible for a user (even experienced users) to tell what's going on or how to work around it. IMO, if this cannot be fixed some other way relatively soon the triggering change will have to be rolled back.

Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality.

Live preview is a fairly new feature that is built with the default wikieditor interface in mind. The normal preview feature (without the 'live' aspect) should work properly.

(The 'live preview' feature can be disabled by unchecking the checkbox at Preferences > Editing > Preview > Show previews without reloading the page)

Live preview is a fairly new feature

It depends how you define ‘fairly new’. Yes, it’s much newer than the internet, even a bit newer than MediaWiki itself, but I wouldn’t call a 17-year-old (c05eeb66755 / rSVN6709 – the 6709th commit in the history of MediaWiki!) feature ‘fairly new’.

Live preview is a fairly new feature

It depends how you define ‘fairly new’. Yes, it’s much newer than the internet, even a bit newer than MediaWiki itself, but I wouldn’t call a 17-year-old (c05eeb66755 / rSVN6709 – the 6709th commit in the history of MediaWiki!) feature ‘fairly new’.

Ah wait I was wrong, I confused this with the fairly recently implemented 'realtime preview' feature, have struck the previous comments :(