Page MenuHomePhabricator

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

Description 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

Version: master
Severity: normal



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).
Phe created this task.Apr 10 2013, 3:02 PM

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.

Tpt added a comment.Apr 10 2013, 5:02 PM

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;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: (the quality status should be completely green)

Phe added a comment.Apr 11 2013, 5:21 PM

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!

GOIII moved this task from Backlog to Done on the ProofreadPage board.Jun 12 2016, 3:46 AM