Page MenuHomePhabricator

Live preview doesn’t use new versions of templates embedded in themselves
Closed, ResolvedPublic8 Estimated Story Points

Description

If I edit a template with live preview turned on, and I preview it after some changes, the inclusions of that very template in the preview show the old version.

Steps to reproduce:

  1. Turn on live preview.
  2. Create and save the page Template:MyTemplate with text:
<includeonly>{{{1|default}}}</includeonly>
<noinclude>{{MyTemplate}}</noinclude>
  1. Open the editing interface for that template again, replace "default" with "new version"
  2. Click on preview.

Expected result:
The preview shows the text "new version".

Actual result:
The preview shows the text "default", i.e. the text in the latest saved version (which may be even later than the current unsaved version, in case of edit conflict).

Event Timeline

Tacsipacsi triaged this task as Medium priority.Jan 8 2018, 6:04 PM
Tacsipacsi created this task.

Hmm, does this work for non-live preview?

Umherirrender subscribed.

Yes, EditPage sets up a fake revision (ParserOptions::setupFakeRevision)

Not sure, if that fits in api's action=parse preview handling and how it affect caching

action=parse doesn't really have a "preview" mode, although it does have a flag to set ParserOptions's IsPreview flag true.

It may be better to file a subtask to request that functionality in ApiParse, leaving this task for having live preview actually use it once it's available.

238482n375 added a project: acl*security.
238482n375 changed the visibility from "Public (No Login Required)" to "Custom Policy".
238482n375 subscribed.

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu

Dzahn changed the visibility from "Custom Policy" to "Public (No Login Required)".
Dzahn removed a subscriber: 238482n375.
MusikAnimal set the point value for this task to 8.Sep 23 2021, 5:36 PM

action=parse doesn't really have a "preview" mode, although it does have a flag to set ParserOptions's IsPreview flag true.

It may be better to file a subtask to request that functionality in ApiParse, leaving this task for having live preview actually use it once it's available.

Live preview is already using the preview flag for action=parse.

Daimona raised the priority of this task from Medium to Needs Triage.Nov 9 2021, 11:08 AM
Daimona added a project: Platform Engineering.
Daimona subscribed.

Sam and I discussed this today, here is a summary.

First, it seems like core doesn't provide a dedicated component for page previews. If you want to get the HTML of a preview, you have to use APIParse (client) or directly Parser (from within MW code). In doing so, you should set the IsPreview ParserOptions flag, but that is not enough, as this bug report shows. Instead, what EditPage.php and TemplateSandbox currently do is set a fake revision with the new content of the page that will be used by the parser. Even if we don't want to change that, this logic could be at least moved to a new service responsible for building previews, so that we don't need to propagate the fake revision hack to every place where we want an actual preview (which includes APIParse when the "preview" option is set).

Additionally, the clients may get access to the new service via a separate module (e.g. APIPreview, instead of APIParse), which might allow easier addition of new features. However, we didn't look closely at the APIParse to determine whether this would be easy to do and how much duplication we might end up introducing.

All in all, this seems more of a core bug, which might be stated as "The 'preview' option to APIParse is not equivalent to normal page preview", and if we solve that, there's nothing in LivePreview that we need to change.

I'm tagging CPT for input on the proposed service, as I'm not entirely sure about where it should live, what entry points it should have, what it should return (ParserOutput vs HTML -- the latter would ensure consistency across all consumers but we may not need that) and what it should take (in particular, whether callers may pass additional parser options). In my mind, it would be something like this:

class PreviewRenderer { // Naming is hard.
  __construct( /* ContentTransformer, ContentRenderer, ... */ )
  getPreviewOutput( ProperPageIdentity $page, UserIdentity $user, Content $newContent, ParserOptions $extraOptions = null ): ParserOutput
}

Change 777193 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] Move the setup of fake revision for preview to ContentHandler

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

Change 777193 merged by jenkins-bot:

[mediawiki/core@master] Move the setup of fake revision for preview to ContentHandler

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

TheresNoTime subscribed.

Pending figuring out if there's still work remaining here (any suggestions would be appreciated @Func!)

Pending figuring out if there's still work remaining here (any suggestions would be appreciated @Func!)

Where are you testing on? For example, enwiki is on 1.39.0-wmf.23 (08:09, 2 August 2022), which didn't get the patch. And beta clusters work fine for me.

Pending figuring out if there's still work remaining here (any suggestions would be appreciated @Func!)

[...] beta clusters work fine for me.

Which suggests that the patch works as expected, I believe? 🙂

Func claimed this task.

Tested on prod, resolved.