For example, this page:

https://ru.wikivoyage.org/wiki/Евпатория

does not display correctly for those users who are not logged in

@Atsirlin, does error show up again after some time on the same page if its cache has been cleared recently?

I wonder if anyone from the parsing team can help as I can't see anything obviously wrong with the code.

Is the template used in Russian identical to the one in English? Is the same problem being hit there?

@Jdlrobson, https://gerrit.wikimedia.org/r/#/c/256409/ was recently merged, which changed ParserOutput::getOutput to ParserOutput::getExtensionData. Its possible that the pages showing no banners might be looking for the banner parameters in ParserOutput::getExtensionData, which will never be set until a cache clear. Hence my above question of "it" recurring even after cache clear.

@Jdlrobson: I have never encountered this problem in English Wikivoyage, and I have not heard any complaints either. The implementation should be similar, but not exactly the same. Perhaps you or Sumit could compare Template:Pagebanner and Mediawiki:Common.css?

@Sumit: My impression is that the problem does not recur after cache purge... at least not on the time scale of several days

Yes, this problem occurs regularly on English Wikivoyage. French Wikivoyage has also reported seeing this issue. Forcing an update to https://en.wikivoyage.org/wiki/Template:Pagebanner typically resolves the issue, but it seems like we have to do so on almost a weekly basis.

Just to clarify (since it seems there may be some confusion), the problem on both Russian and English Wikivoyage isn't that the banner does not appear, it is that the TOC appears within the article rather than as part of the banner.

Thanks for clarification @Wrh2
I'm puzzled about what's going on here. Are there any other extensions deployed that may be tinkering with the table of contents?

I'm not aware of any other TOC extensions. I suspect that the behavior may occur during the weekly(?) Mediawiki software updates. Is it possible the banner extension isn't enabled until after the cache has started rebuilding following a software update?

Please revert https://ru.wikivoyage.org/w/index.php?title=MediaWiki:Vector.js&diff=168539&oldid=167688 immediately. If we need to clear the parser cache, we can use touch.py, bump $wgCacheEpoch, or some other method. That JavaScript hack effectively disables the cache for everyone.

@Legoktm: Frankly speaking, for a small project like Wikivoyage the cache brings no obvious benefits, but triggers many serious issues including the problem of page banners and ToC. The dirty trick of automatic cache purge worked perfectly fine in the last 3 weeks, and I believe that it could be used further even if it violates some general philosophy of the Mediawiki software. I am fine with having this cache purge feature reverted, but you have to propose another solution. At this point, having stable page banners and ToC is very important for us, while anything related to the cache is of minor relevance to the project.

Diff between cached and rendered:

Visual comparison, for reference:

Not sure if the following might reveal a pattern that anyone recognizes, but here are the times that I've purged the pagebanner cache on English Wikivoyage after encountering in-article TOCs during the past two weeks (per https://en.wikivoyage.org/w/index.php?title=Template:Pagebanner&action=history):

• 19:42, 4 January 2016‎
• 09:07, 1 January 2016
• 10:05, 27 December 2015
• 18:11, 23 December 2015
• 15:46, 19 December 2015

Earlier in December and in November I either wasn't editing frequently enough to notice that the cache needed purging, or else the issue wasn't occurring as frequently.

Is the problem with the parser cache or Varnish? Do you need an actual purge to fix it, or is adding some cachebreaker like ?_=21947979 to the end of the URL enough to show the correct banner?

In T121135#1915771, @Tgr wrote:

Is the problem with the parser cache or Varnish? Do you need an actual purge to fix it, or is adding some cachebreaker like ?_=21947979 to the end of the URL enough to show the correct banner?

It's not a browser cache issue, if that's what you're asking. I have to edit the shared template to trigger Mediawiki to rebuild the page cache for all articles with page banners when the problem occurs.

No, what I want to verify is that it's not a Varnish cache issue.

I'll need to test out the query param the next time the issue occurs. I just forced a cache flush yesterday, so it will probably be at least 2-3 days.

The issue is re-occurring today, even with the cache-buster param:

https://en.wikivoyage.org/wiki/Gilimanuk?_=21947979

That seems like a pretty regular 4-day schedule; too short for the MediaWiki software updates (which should have no effect anyway, plus they were on hold through most of December). When you see the issue, does it affect some pages or all of them? Can you not flush the next time so we can look what's in the cache?

From the sources copied by jcrespo:

! <!-- Saved in parser cache with key enwikivoyage:pcache:idhash:29776-0!*!0!!en!4!* and timestamp 20151228124224 and revision id 2793915
! <!-- Saved in parser cache with key enwikivoyage:pcache:idhash:29776-0!*!0!!en!4!* and timestamp 20151230232900 and revision id 2793915

So this does not seem related to some parser cache split; the page is simply rendered differently at different times.

When the issue occurs it happens on a random subset of articles. I saw it several times last night, and after hitting "random page" many, many times this morning I found the following two articles which are showing an in-article TOC:

https://en.wikivoyage.org/wiki/Jorepokhri
https://en.wikivoyage.org/wiki/Megaplatanos

Thanks! I was wondering whether something sets a shorter expiry since your purges seemed to happen on a fairly regular 4-day schedule but apparently not. Also, the bannertoc parameter is neither set in page props nor extension data.

tgr@mw1152:~$ mwscript eval.php --wiki=enwikivoyage
> $title = Title::newFromText( 'Jorepokhri' );
> $page = WikiPage::factory( $title );
> $parserOptions = ParserOptions::newFromUser( User::newFromName( 'Tgr_(WMF)' ) );
> echo ParserCache::singleton()->getKey( $page, $parserOptions );
enwikivoyage:pcache:idhash:16490-0!*!0!!en!*!*
> $parserOutput = ParserCache::singleton()->get( $page, $parserOptions );
> echo $parserOutput->getCacheExpiry();
2592000
> var_dump( $parserOutput->mProperties );
array(4) {
  ["wpb_banner"]=>
  string(28) "Mena-asia default banner.jpg"
  ["wpb_banner_focus_x"]=>
  int(0)
  ["wpb_banner_focus_y"]=>
  int(0)
  ["wikibase_item"]=>
  string(9) "Q14219880"
}
> var_dump( $parserOutput->getExtensionData( 'wpb-banner-options' ) );
array(7) {
  ["tooltip"]=>
  string(10) "Jorepokhri"
  ["title"]=>
  string(10) "Jorepokhri"
  ["extraClass"]=>
  string(0) ""
  ["enable-toc"]=>
  bool(true)
  ["data-pos-x"]=>
  int(0)
  ["data-pos-y"]=>
  int(0)
  ["name"]=>
  string(28) "Mena-asia_default_banner.jpg"
}

I'm not sure what else to look at. We should probably log debug data when the page is parsed so we can see whether this is tied to a specific client or an API call or something.

Pinging Jdlrobson as I believe that this issue is the one being referenced in the English Wikivoyage discussion earlier today: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Pagebanner_-_why_cannot_it_not_be_fixed

@Whr2 have there been any reports of this happening on pages that have been edited since the 4th March? MobileFrontend was causing an issue with TOC rendering which should have been fixed since then.

If you can point me at a new example I can debug this further.

In T121135#2182312, @Jdlrobson wrote:

@Whr2 have there been any reports of this happening on pages that have been edited since the 4th March? MobileFrontend was causing an issue with TOC rendering which should have been fixed since then.

If you can point me at a new example I can debug this further.

I see it multiple times each week, and it has definitely still been occurring since March 4. After hitting "random page" three times on Wikivoyage just now I reached https://en.wikivoyage.org/wiki/Hatsukaichi which is showing the TOC in the article instead of the banner as of 4:10PM Pacific time.

Cache is cleared fairly regularly even if articles aren't edited - I've made minor updates to Template:Pagebanner numerous times over the past months, which forces a cache flush of all articles with page banners.

https://en.wikivoyage.org/wiki/Kedung_Kayang says it was last edited on 10 March 2016 and I'm seeing an in-article TOC.

Thanks. Then it's definitely not fixed. Looking at source it looks like the exact same problem as we had on Wikipedia so hopefully I can get to the bottom of this and we can fix it in a similar way...

In T121135#1910435, @Atsirlin wrote:

@Legoktm: Frankly speaking, for a small project like Wikivoyage the cache brings no obvious benefits, but triggers many serious issues including the problem of page banners and ToC. The dirty trick of automatic cache purge worked perfectly fine in the last 3 weeks, and I believe that it could be used further even if it violates some general philosophy of the Mediawiki software. I am fine with having this cache purge feature reverted, but you have to propose another solution. At this point, having stable page banners and ToC is very important for us, while anything related to the cache is of minor relevance to the project.

That JS hack, if I'm reading it correctly, effectively sends us a purge on every pageview? That's horrendous and abusive of our infrastructure, and the problem could grow if people start copying it to other wikis to work around other perceived problems.

In T121135#2182349, @Wrh2 wrote:

Cache is cleared fairly regularly even if articles aren't edited - I've made minor updates to Template:Pagebanner numerous times over the past months, which forces a cache flush of all articles with page banners.

https://en.wikivoyage.org/wiki/Kedung_Kayang says it was last edited on 10 March 2016 and I'm seeing an in-article TOC.

I'm not too familiar with template logic but I see in https://en.wikivoyage.org/wiki/Template:Pagebanner:

>| toc={{#ifeq: {{{notoc|}}} | true | no | yes }}

can you explain what this means?
It seems to me that when I pass toc=no or toc=false I get a table of contents in the HTML outside the banner - https://en.wikivoyage.org/wiki/User:Jdlrobson/test

This seems suspicious to me and might be having unexpected side effects somewhere in the stack.
Can you update the template so that it omits the parameter when not provided and applies NOTOC? e.g. https://en.wikivoyage.org/wiki/User:Jdlrobson/test2

Let's see if that gets us anywhere...

If the template was at fault the behavior should be consistent - currently if a page is edited or flushed from the cache the banner always shows correctly, but after some time passes TOCs start showing up within articles, which doesn't seem like a template issue to me. I can update the template, but doing so will flush all banners on the site and it will be several days until the problem shows up again - if you don't need to see any example pages to debug further let me know if it's safe to update the template. Also, are you certain you want NOTOC? That would suppress the TOC from both the article and the banner if I'm understanding correctly, which doesn't seem right.

To explain what the template code is doing:

toc={{#ifeq: {{{notoc|}}} | true | no | yes }}

Per https://www.mediawiki.org/wiki/Extension:WikidataPageBanner the page banner extension takes a parameter of "toc=yes" or "toc=no" to determine whether to display the TOC in the banner or in the article. This template code says that when a "notoc" param is passed to the template with the exact value of "true" that the pagebanner will be invoked with "toc=no"; at all other times it will be invoked with "toc=yes".

In T121135#2182584, @Wrh2 wrote:

If the template was at fault the behavior should be consistent - currently if a page is edited or flushed from the cache the banner always shows correctly, but after some time passes TOCs start showing up within articles, which doesn't seem like a template issue to me. I can update the template, but doing so will flush all banners on the site and it will be several days until the problem shows up again - if you don't need to see any example pages to debug further let me know if it's safe to update the template. Also, are you certain you want NOTOC? That would suppress the TOC from both the article and the banner if I'm understanding correctly, which doesn't seem right.

To explain what the template code is doing:

toc={{#ifeq: {{{notoc|}}} | true | no | yes }}

Per https://www.mediawiki.org/wiki/Extension:WikidataPageBanner the page banner extension takes a parameter of "toc=yes" or "toc=no" to determine whether to display the TOC in the banner or in the article. This template code says that when a "notoc" param is passed to the template with the exact value of "true" that the pagebanner will be invoked with "toc=no"; at all other times it will be invoked with "toc=yes".

Okay so it's doing what it's supposed to. Working hard to see if I can replicate this locally.
Is someone able to check if any extension calls ParserOutput->setText in the Wikivoyage setup?

@Tgr could you do me a favour and check what the value of $parserOutput->getTOCEnabled and getTOCHTML is on the cached ParserOutput for that page?

My current theory is that under some circumstances the banner is generated before the table of contents has been generated and thus doesn't successfully disable it and replace it.

Change 281995 had a related patch set uploaded (by Jdlrobson):
Attempt at fixing table of contents problem

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

I've spent hours on this and although I cannot replicate I would like to try https://gerrit.wikimedia.org/r/281995 in production to see if it makes the issue go away. I'd like to swat this Tuesday - can anyone help me with that? I'll revert it if it doesn't prove to help and then escalate it to the Parsing team.

Thanks to @Tgr I've confirmed that the issue is that ParserOutput::getTOCEnabled is false for these pages:
https://phabricator.wikimedia.org/P2887

This causes the code block not to run.
I'm not sure why this is false when the table of contents is added to the page. Will investigate this further, but it seems my patch should make the issue go away. Hoping to get that SWATed asap.

Change 282994 had a related patch set uploaded (by Jdlrobson):
Attempt at fixing table of contents problem

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

Change 282995 had a related patch set uploaded (by Jdlrobson):
Attempt at fixing table of contents problem

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

This is on the SWAt calendar for Wednesday 9:00PST
https://wikitech.wikimedia.org/wiki/Deployments#Wednesday.2C.C2.A0April.C2.A013

I'm working UK hours so cannot do this any sooner.

Change 281995 merged by jenkins-bot:
Attempt at fixing table of contents problem

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

Change 282995 merged by jenkins-bot:
Attempt at fixing table of contents problem

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

Change 282994 merged by jenkins-bot:
Attempt at fixing table of contents problem

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

@Atsirlin can you make an update the pagebanner template to force a cache flush for the pages that use the banner? After doing so on English Wikivoyage I am yet to find a page with the toc issue so I'm considering this fixed but would like to check all is good your end before I declare it so.

Note after editing the template it could take up to 30 minutes to come into effect.

In T121135#2203890, @Jdlrobson wrote:

@Atsirlin can you make an update the pagebanner template to force a cache flush for the pages that use the banner? After doing so on English Wikivoyage I am yet to find a page with the toc issue so I'm considering this fixed but would like to check all is good your end before I declare it so.

In the past manually flushing the cache by editing Template:PageBanner fixed the issue for all articles, but within a few days articles with bad TOCs would start building up again, so I would wait a couple of weeks to see if the problem re-occurs before declaring this issue resolved.

So here are some facts

• On pages impacted by the bug, when queried ParserOutput->getTOCEnabled returned false despite a table of contents being rendered in the page with no sign of NOTOC.
• Pages impacted by bug only surfaced 1-2 weeks after the template was updated suggesting either the API or a background job is updating the value

@MaxSem @EBernhardson my theory is that there is a job somewhere which calls setTOCEnabled on the ParserOutput and this gets stored in cache. I consider this cache pollution.

There doesn't seem to be
too many users of this so I figure this is either caused by the MobileFrontend API or CirrusSearch Updater.php

Any theories?

Can we safely call this closed from the community perspective @Atsirlin and @Wrh2 ? Any new reports?

While I haven't noticed the issue in the past week, if there's no harm in doing so I would leave this open for another week just to be certain. The weekly (Wednesday?) software release seems to have been a trigger for this issue in the past, but if I'm reading https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Server_switch_2016 ("There will be a code freeze for the week of 18 April") correctly then there was no release this week.

No harm, just wanted to check in whether things are looking good. Sounds like they are :)

@Wrh2, okay if we close this task now?

I haven't seen the issue re-occur since the change went live, so I think it should be OK to close this issue now. I just clicked on "Random page" about 50 times and all articles had correct TOCs. Thanks to everyone who helped investigate.

Since the original issue was sporadic, if the problem should re-occur in the future, is is the correct process to open a new ticket or to re-open this ticket?