Page MenuHomePhabricator

quality status of page using <pages tag doesn't match the expected status
Closed, DeclinedPublic

Description

http://fr.wikisource.org/wiki/%C3%80_un_martyr transclude six page with a <pages index="..." from=77 to=82, these six pages are marked as not proofread, the quality status should be red (under the page title). But actually the quality status is the status of the whole book not only the status of these six pages. As a side effect saving a page is very slow as the query to get the status is heavy. This behavior doesn't occur on en.wikisource.org.


Version: master
Severity: normal

Details

Reference
bz47077

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:26 AM
bzimport added a project: ProofreadPage.
bzimport set Reference to bz47077.
bzimport added a subscriber: Unknown Object (MLST).

Are there other examples of this?
Are there indicators that this a new behavior?
Asking a I don't yet see how this issue is highest priority and critical.

In order to get the quality status of Page: pages transcluded in a ns0 page, Proofread Page get the status of all Page: listed in the templatelinks table by getting for each ones the relevant quality category (see
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/ProofreadPage.git;a=blob;f=ProofreadPage.body.php;h=820116e5e192af272f92abdb8405793be1807c11;hb=23423c096581f1e6bc36a84115d4dc44253d1645#l1715 ).

But not only pages directly transcluded in the current page are in this table but also pages transcluded in a page transcluded in the current page, that cause to have too much pages as needed in the bar.

After some investigation, this issue is not really new and the number of pages affected is low, so I reduce the severity to "normal".

An other example: https://fr.wikisource.org/wiki/Les_Boh%C3%A9miens_%28B%C3%A9ranger%29 (the quality status should be completely green)

We tracked our trouble to the use in a module of frame:preprocess() with the frame of the page calling a template which invoke the module, some uneeded evaluation of template argument was done as a side effect of the call to preprocess(). We solved that by using frame:newChild(title = ..., args = {}) to create an empty frame.

Thanks for sharing the workaround here!