Page MenuHomePhabricator

Parsoid has no special handling for the properties set by WikidataPageBanner
Closed, InvalidPublic

Description

The pagebanner extension doesn't seem to work with the api=parse and api=expandtemplates endpoints. This affects all clients that use these mediawiki API endpoints.

See the output of http://pagebanner.wmflabs.org/w/api.php?action=expandtemplates&text={{PAGEBANNER:Toledo_banner_Puerta_de_Alfonso_VI.jpg}}
Compare against the output of http://pagebanner.wmflabs.org/w/api.php?action=expandtemplates&text={{uc:Toledo_banner_Puerta_de_Alfonso_VI.jpg}}

The expandtemplates API endpoint should be able to return the wikitext corresponding to the execution of a transclusion / parser function.

Similarly the parse API endpoint should be able to return the parsed HTML corresponding to the wikitext.
But, see http://pagebanner.wmflabs.org/w/api.php?action=parse&text={{PAGEBANNER:Toledo_banner_Puerta_de_Alfonso_VI.jpg}}
Again, compare with http://pagebanner.wmflabs.org/w/api.php?action=parse&text={{uc:Toledo_banner_Puerta_de_Alfonso_VI.jpg}}

Specifically, Parsoid (as one client of the mediwiki API) uses the api=expandtemplates endpoint to support transclusions (parser functions and templates) -- it uses the endpoint to fetch the expanded wikitext for the transclusions. This has 2 impacts:

  1. Parsoid's rendering of these pages will be different from the PHP parser rendering
  2. Editing of these pages in visualeditor will be affected -- it will not corrupt those pages, but the banner will not show up and you may not be able to edit these transclusions.

Event Timeline

Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task to Backlog on the Wikidata-Page-Banner board.
Jdlrobson added subscribers: Jdlrobson, ssastry.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
ssastry set Security to None.
ssastry renamed this task from Pagebanner and Parsoid functions to Pagebanner extension and api=parse and api=expandtemplates endpoinds.Aug 4 2015, 9:26 PM
ssastry updated the task description. (Show Details)

The API output is correct. That parser function returns no text, and sets a property with name "wpb-banner-options". The extension uses a BeforePageDisplay hook to modify the HTML depending on the wpb-banner-options property. The action=expandtemplates module does not, and should not, call the BeforePageDisplay hook.

Parsoid fetches the ParserOutput properties but has no special handling for wpb-banner-options. Presumably it should be handled in a similar way to DISPLAYTITLE and DEFAULTSORT.

tstarling renamed this task from Pagebanner extension and api=parse and api=expandtemplates endpoinds to Parsoid has no special handling for the properties set by WikidataPageBanner.Aug 5 2015, 12:34 AM
ssastry triaged this task as Medium priority.Aug 13 2015, 3:35 AM

The API output is correct. That parser function returns no text, and sets a property with name "wpb-banner-options". The extension uses a BeforePageDisplay hook to modify the HTML depending on the wpb-banner-options property. The action=expandtemplates module does not, and should not, call the BeforePageDisplay hook.

Yes, WikidataPageBanner only adds banner HTML in BeforePageDisplay hook. Is there a way to return banner HTML during parse, or a place where a similar functionality has been implemented before?

Deskana lowered the priority of this task from Medium to Lowest.Feb 23 2018, 4:28 PM

A number of recent changes have been made which may have magically fixed this:
a) Parsoid gained the ContentMetadataCollector interface, implemented by ParserOutput. So extensions which register 'out of band' data (ignored by Parsoid) ought to have that data passed through Parsoid unchanged. (T287216)
b) WikidataPageBanner was updated to use the new ToC interfaces (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikidataPageBanner/+/884371)

I think this task should perhaps be closed as invalid. As Tim mentions earlier in the task, it's doing the right thing - the template leads to properties in the parser output object.

The banner itself is not part of the content. It is meta data that is used to render the article.

Presumably the motivation behind this task was that from a user perspective it would be useful if the banner showed in VisualEditor and updated with changes to the template, but if that's desired it would be best to approach that using the existing hooks (both client and server)

The banner currently (for better or worse) seems to be inserting itself inside the subtitle region not the parser content area.