Let's get to the bottom of why
Purging seems to take care of the problem
Let's get to the bottom of why
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
WikidataPageBanner add a separate flag for toc | mediawiki/extensions/WikidataPageBanner | master | +3 -3 |
@Sumit is seems we set 'toc' to true and then replace it with html when isTOCEnabled.
We should make sure that we do not set template parameters to anything other than something used by the template e.g. toc should either be empty string or the table of contents itself.
My guess is that previously table of contents was disabled by the NOTOC directive and the toc parameter was provided so as a result the toc parameter doesn't get substituted.
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.
Change 248277 had a related patch set uploaded (by Sumit):
WikidataPageBanner add a separate flag for toc
I was unable to reproduce the issue locally, however still I've added a patch to separate actual toc from the flag which stores true or false to show toc or now. That should hopefully solve the issue.
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".
The problem only started occurring in the past several weeks, so assuming it is not yet fixed, it seems likely that it was introduced by a recent change.
Unfortunately since the table of contents is baked into the page HTML there is no way to fix existing pages edited before today -we'll have to wait for them to rectify themselves :-( but this change should stop it happening again. Let me know if you see a page edited since today that has the problem as then that would mean things are more serious than we expected!
I did a manual purge on a few pages for the change to take effect and hopefully the problem seems to be fixed, so as the pages get purged, problem should go away.
Actually I had an idea...
Add this code to MediaWiki:Mobile.js and it will purge existing pages when the problem is encountered (e.g. crowd source purging the cache where needed)
if ($( '.wpb-banner-toc' ).text() === '1' ) { $.post( mw.util.getUrl( mw.config.get( 'wgTitle' ), { action: 'purge' } ) ) }
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.
You can also put this in MediaWiki:Vector.js (more users on desktop so might get resolved quicker)
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.