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.

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.

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.

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.

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.

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.

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

ListingEditor2 is just the beta listing editor gadget (not enabled by default), used to test changes to the listing editor (which is enabled by default). At the moment there are no beta features being tested, but the next time something comes up I'll make sure that your changes aren't lost.

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:

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

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.

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?

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):

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?

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.

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.

In T51015#1836131, @Mdann52 wrote:

Is this still an issue, or has it been resolved?

I don't recall seeing a "1" for the TOC since we purged the cache for all articles last week, so it's probably safe to call this issue resolved now.

On English Wikivoyage I just made a minor edit to https://en.wikivoyage.org/wiki/Template:Pagebanner which should hopefully force a cache purge for all pages using that template. It seems to have done the trick for the handful of pages that I checked - https://en.wikivoyage.org/wiki/Culver_City showed the problem earlier this morning but is displaying correctly now.

It may be too early for feedback since the updated extension apparently just went out today, but in a random sample of articles on Wikivoyage just now I would say that the majority of them exhibited the behavior with the incorrect TOC, so it may be premature to mark this issue as "resolved".

I'm not sure if this is helpful or not, but when this issue first surfaced it was proposed that it might be a caching issue, and that over time it would go away. https://en.wikivoyage.org/wiki/Morro_Bay is an article that I have edited since the extension was updated (most recently on 15-October), it was working fine when I edited it, and today it is showing "1" for the TOC, so I think that rules out a cache problem.

In T112608#1641865, @coren wrote:

The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers).

As far as I can tell, that covers everything.

In T112608#1640292, @Negative24 wrote:

Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)

The individual who originally reported this issue now also says it is fixed. Thanks again Sumit - this task can now be closed.

I was unable to reproduce the issue just now, but have also asked for feedback from the original reporters at https://en.wikivoyage.org/wiki/Wikivoyage:Travellers'_pub#banner_not_displaying.

The fix seems to be working on Wikivoyage, this issue can be closed.

@Sumit - see my second comment on this ticket. I've tried updating my common.js file with the Javascript Jdlrobson suggested, as well as the Javascript you provided, but in both cases I'm still able to reproduce the problem. It appears that either Firefox is firing the onload event before the image is loaded or else JQuery is failing at a height calculation early in the load process.

@Jdlrobson I tried the code you provided in my local common.js, and I also tried executing it on window.load (since the JQuery load event handler can be flaky) but was still able to reproduce the issue.

Thanks for the quick response & patch!

In T93106#1173339, @Nemo_bis wrote:

Wikivoyage in what language? What language editions have been contacted about this proposal?

I'm a bit concerned as to whether there are sufficient requirements to ensure that someone who isn't already familiar with Wikivoyage will be able to implement a solution that is actually going to be used on Wikivoyage. Currently page banners work just fine on the full site, although they are definitely a hack. Is the goal of the extension solely to return a banner image sized appropriately for the user's browser on page load? Will the extension also implement the current Javascript functionality that resizes the banner when the user resizes the browser window? Will the extension implement the table of contents overlay, or the icon overlays (see https://en.wikivoyage.org/wiki/Template:Pagebanner)? Is this proposal solely meant for use on mobile, and something that won't be used for the full site? Or is it part of the GSOC project to figure out how to answer these questions and implement an extension that offers all of the functionality of the current template?

In T77925#1091036, @Jdlrobson wrote:

@Wrh2 any ideas from an editors perspective how you would like this to work without templates?

Ideally I would imagine an edit button on the banner which when clicked pops up an input field where you can search for an image on commons and saves as a page property separate to wikitext. Would this be sufficient or would it need to be part of the wiki text?

In T77925#1098331, @Sumit wrote:

Just out of curiosity, the wikivoyage home page uses the banner template( http://en.wikivoyage.org/wiki/Template:Banner ) to render the banners there, which are not included in mobile. Can we also include this functionality in the proposed extension, so that wikivoyage home page has banners in mobile as well?

In T77925#1078790, @Jdlrobson wrote:

@Wrh2 this would be the hope.
The only remaining question here seems to be how to override the Wikidata property. Where would such a value get stored (note this extension would deprecate the need for the template)

If this proposal does move forward there needs to be a way to locally override the Wikidata property, as has been previously mentioned. Additionally, if possible, a major shortcoming of the current banners is that they require hiding the <h1> tag with "display:none" CSS, and the banner then uses a <div> for the article name in the banner (using a h1 tag in wiki source causes the page name to appear in the TOC), which is horrible for SEO. If there was a way to move this functionality to an extension and have an <h1> tag in the banner that contains the article name without causing a TOC update, that would be an additional win.