Page MenuHomePhabricator

For anonymous users the Index namespace pages are not displaying "page status" in desktop view ($wgTitle not set in GetLinkColours hook)
Closed, ResolvedPublic

Description

As an anonymous user, when viewing an index page in desktop mode, the page statuses of pages do not display

https://en.wikisource.org/wiki/Index:The_empire_and_the_century.djvu

image.png (550×768 px, 50 KB)

yet if viewed in the mobile mode, it does show

image.png (660×762 px, 53 KB)

As a logged-in user, it will also show normally/as expected.

Event Timeline

As a logged-in user, it will also show normally/as expected.

It's interesting. As a logged-in user they whee not shown to me but if I try to edit the page and ask for a preview it works.

It looks like a cache problem.

As a logged-in user, it will also show normally/as expected.

It's interesting. As a logged-in user they whee not shown to me but if I try to edit the page and ask for a preview it works.

It looks like a cache problem.

if it is a cache issue, why does a hard purge reset the display to null page status.

After some changes in pages, the page colouring in index tends to disappear. The index page needs to be purged to dispay colours again.

Moreover, I observed sometimes that purging for anonymous and/or logged in users works independently (purging as anonymous may be needed in such case).

So, maybe, some coincidence ot these two effects?

I purged the page as logged in (it was not coloured for me as logged in) and now I see colours as both: anonymous & logged in.

For anonymous user, index pages that I view randomly the pages show without page status in anonymous, though are showing with page status as logged-in user. If I purge (and wait) doesn't matter whether I am logged -in or anonymous to purge, then the Index: pages do update and remain updated.

  • randomly = using enWS's Random transcription (sidebar) to get files

@Billinghurst Is the problem still happening now that the quality color bug is solved?

For me the pages in this index are neither coloured when I am logged in nor when I logout.
I think this is a problem after a page related to this index is changed (after such an action page colouring in index tend to disappear until the index is purged).
I am unsure what is the source of this problem (caching procedures incompatible with some changes in proofreadpage?). But I notice this on many wikis since about the change that modified relation between index and pages (from linking to transclusion).

I generally do not notice this effect in pl.ws (probably because a gadget or bot is purging the index or doing something similar), but I regularily notice that on all other wikisources. A purge helps.

Maybe some .js could be used to purge any index page when it is being displayed? But unsure: this would be a bad hack workaround for the problem that hides it instead os solving it. And possibly generating some overload for servers.

null edit kills the page status colouration for anonymous logins. Purge will bring it back.

similarly any Page: namespace edit kills the page status colouration

There are no colors because the CSS classes like prp-pagequality-4 quality4 are missing from the page HTML. They should be added in the GetLinkColours hook handler. However, it seems that $wgTitle is not set when this code runs, so ProofreadPage skips the hook entirely. (Normally $wgTitle is used to check the namespace of the page being parsed, as quality4 etc. is only added in the 'Index' namespace.) I am not sure why this stopped working suddenly, possibly it is not available anymore when the parsing happens in the job queue?

Using $wgTitle is not recommended anyway, see T25307: Send $wgTitle to the fiery pit from whence it came.

I see two ways to fix this:

  • Remove the namespace check and always add the classes, and use CSS to only add the colors to them in the 'Index' namespace
  • Make MediaWiki pass a $title parameter to the GetLinkColours hook, and use that instead of the global title

I would prefer the second solution.
The first one might increase size of large pages (eg. novels transcluding ~1000 book pages) for 10-20kB and trigger them to hit the page size limit.

I have no knowledge of which is the best way to fix it, I suspect all pages is gross overkill rather than targeting the Index: ns.

Re the "why" possibly with the change at T196971 in late June

There is a gadget in sourceswiki that is a temporary workaround for this problem (purging the index if colors disappeared):
https://wikisource.org/wiki/MediaWiki:Gadget-purgeindex.js

It should work as gadget as well as in user's common.js

I suggest not to put it into the site-wide MediaWiki:Common.js as it may (theoretically) loop in a rare unpredictable case when it failes. So a user should be able to disable it.

matmarex renamed this task from For anonymous users the Index namespace pages are not displaying "page status" in desktop view to For anonymous users the Index namespace pages are not displaying "page status" in desktop view ($wgTitle not set in GetLinkColours hook).Jul 30 2018, 2:07 PM

Change 449230 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] Pass $title to 'GetLinkColours' hook

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

Change 449231 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/ProofreadPage@master] Use new $title parameter to 'GetLinkColours' hook instead of $wgTitle

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

matmarex triaged this task as Low priority.

Change 449230 merged by jenkins-bot:
[mediawiki/core@master] Pass $title to 'GetLinkColours' hook

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

Change 449231 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Use new $title parameter to 'GetLinkColours' hook instead of $wgTitle

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

matmarex removed a project: Patch-For-Review.

The fix will be deployed to Wikimedia wikis this week (Wikisources are on Wednesday: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20180801T1900).

After that you have to wait for the HTML cache to expire (expiry is set to 2 weeks these days, I believe), or purge affected pages.