I should clarify that in my sandbox, the templates transclude as expected. Another user also copied the Main page code entirely to their sandbox, and it displayed correctly there.

When previewing changes to the Main page, the latest version of the templates is also displayed, but reverts to the cached version when saving changes.

Probably caused by FlaggedRevs still trying to handle templates, which seems to be the default setting. Hmm, I should probably fix that.

Yeah ... T411328 implies that could still be a problem.

Change #1271839 had a related patch set uploaded (by Pppery; author: Pppery):

[operations/mediawiki-config@master] Enwikinews: disable lingering FlaggedRevs template processing

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

Change #1271839 merged by jenkins-bot:

[operations/mediawiki-config@master] Enwikinews: disable lingering FlaggedRevs template processing

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

Mentioned in SAL (#wikimedia-operations) [2026-04-15T20:36:59Z] <jforrester@deploy1003> Started scap sync-world: Backport for [[gerrit:1268300|Drop 1.5x logos (T246054)]], [[gerrit:1271839|Enwikinews: disable lingering FlaggedRevs template processing (T423512)]], [[gerrit:1270583|Record file usage from TemplateStyles pages (T413707)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-15T20:38:53Z] <jforrester@deploy1003> jforrester, bawolff, pppery: Backport for [[gerrit:1268300|Drop 1.5x logos (T246054)]], [[gerrit:1271839|Enwikinews: disable lingering FlaggedRevs template processing (T423512)]], [[gerrit:1270583|Record file usage from TemplateStyles pages (T413707)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-15T20:46:14Z] <jforrester@deploy1003> Finished scap sync-world: Backport for [[gerrit:1268300|Drop 1.5x logos (T246054)]], [[gerrit:1271839|Enwikinews: disable lingering FlaggedRevs template processing (T423512)]], [[gerrit:1270583|Record file usage from TemplateStyles pages (T413707)]] (duration: 09m 15s)

The above patch does not appear to have fixed the issue. Looking at the code it seems possible that the bad parser output is being cached, in which case a null or dummy edit might fix it. Otherwise I have no idea.

I've tried a null/dummy edit to the Main page. All the Lead templates were edited, effectively achieving the same things as a null edit. I've also tried a null edit on the Lead's parent template: https://en.wikinews.org/wiki/Template:Lead_2.0.

I'll try deleting and recreating templates.

I created a new template (one that has never had FlaggedRevs), moved the old then moved the new to the same name. I then verified it will update as expected.

@Pppery, can you think of any reason why I shouldn't replace all lead templates in a similar manner?

Given the pending closure of Wikinews, do you expect that this is the quickest and easiest work-around?

Thanks for helping.

I can't think of any reason why that wouldn't work. No idea why FlaggedRevs is misbehaving, though.

I’ve recreated all five templates, and normal functionality appears to be restored. I’ve also made several updates to the templates and confirmed they are behaving as expected. I haven't noticed this anywhere else, but given that the project is pending closure, what else should/could we do to make sure nothing else is broken before the site is set to read-only?

Thank you in advance.

I just realized, we are likely seeing this issue elsewhere as well. We are in the process of converting DPLs to static lists in various templates, and we've noticed some are not updating. See the following discussion:

https://en.wikinews.org/wiki/Wikinews:Admin_action_alerts#c-Metropolitan90-20260413125400-Michael.C.Wright-20260413122500

Since we have several hundreds of templates that use DPL, we are considering using a bot to update all of those templates. If those changes aren't propagated to transcluding pages like they weren't for the Main page, we could have many pages that ultimately render unpredictably once DPL is disabled and the site is set to read-only.

In T423512#11826975, @gerritbot wrote:

Change #1271839 merged by jenkins-bot:

[operations/mediawiki-config@master] Enwikinews: disable lingering FlaggedRevs template processing

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

@A_smart_kitten asked me to take a look at this (see #wikimedia-tech today) and AFAICT this patch has no effect – $wgFlaggedRevsHandleIncludes is still 2 on enwikinews:

lucaswerkmeister-wmde@deploy1003 ~ $ mw-debug-repl enwikinews
Becoming root...
Finding a mw-debug pod in eqiad...
Now running shell.php for enwikinews inside pod/mw-debug.eqiad.pinkunicorn-67bff79f84-gvlnl on release pinkunicorn...
Psy Shell v0.12.20 (PHP 8.3.30 — cli) by Justin Hileman
> $wgFlaggedRevsHandleIncludes
= 2

I don’t understand why that’s the case (some weird load order behavior?), but moving the override to InitialiseSettings.php (where there are already $wgFlaggedRevsHandleIncludes overrides for other wikis) seems to work better. I tried that out on mw-experimental (using P84273 from T405688) and it seems to work:

lucaswerkmeister-wmde@deploy1003 ~ $ .local/bin/mw-exp-shell mw-experimental eqiad
Activating env for mw-experimental in eqiad...
Found a pod! mw-experimental.eqiad.pinkllama-5db88dd9d8-4zc42
www-data@mw-experimental-eqiad:/$ php /srv/mediawiki/multiversion/MWScript.php shell enwikinews
Psy Shell v0.12.20 (PHP 8.3.30 — cli) by Justin Hileman
> $wgFlaggedRevsHandleIncludes
= 0

(Edited to use the correct wiki in the last block, my bad.)

Change #1273763 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[operations/mediawiki-config@master] enwikinews: Move override for $wgFlaggedRevsHandleIncludes to InitialiseSettings.php

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

For the record, @Lucas_Werkmeister_WMDE & myself tested my patch using mw-experimental & WikimediaDebug; and - after purging the cache of 'Tour de France: Alberto Contador wins the grand tour' while connected to mw-experimental - the updated version of the Template:Tour de France 2007 seemed to be displayed on that page. (Though sometimes it might've taken few reloads after purging the cache, for some reason. But the main thing is that it seemed to work, right? :D)
[ #wikimedia-operations logs ]

That's ridiculous. I had thought all of the FlaggedRevs code was in flaggedrevs.php. It makes even less sense for half of it to be there and half of it to be somewhere else. But thank you for investigating.

Change #1273763 merged by jenkins-bot:

[operations/mediawiki-config@master] enwikinews: Move override for $wgFlaggedRevsHandleIncludes to InitialiseSettings.php

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

Mentioned in SAL (#wikimedia-operations) [2026-04-17T15:20:42Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1273763|enwikinews: Move override for $wgFlaggedRevsHandleIncludes to InitialiseSettings.php (T423512)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-17T15:22:26Z] <lucaswerkmeister-wmde@deploy1003> lucaswerkmeister-wmde, asmartkitten: Backport for [[gerrit:1273763|enwikinews: Move override for $wgFlaggedRevsHandleIncludes to InitialiseSettings.php (T423512)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-17T15:27:33Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1273763|enwikinews: Move override for $wgFlaggedRevsHandleIncludes to InitialiseSettings.php (T423512)]] (duration: 06m 51s)

$wgFlaggedRevsHandleIncludes is 0 on enwikinews now, hopefully that also corresponds to more sensible on-wiki template behavior.

Thanks for deploying @Lucas_Werkmeister_WMDE!
@Michael.C.Wright Let us know if things are now working on enwikinews from your / the community's perspective, following the most recent patch :)

In T423512#11833733, @Pppery wrote:

That's ridiculous. I had thought all of the FlaggedRevs code was in flaggedrevs.php. It makes even less sense for half of it to be there and half of it to be somewhere else. But thank you for investigating.

No problem :) happy to help.

In T226410#5375822, @Tgr wrote:

[...] (Ain't flagrev config a bundle of fun?)

:p

So far, so good. Thank you all for lending a hand!

I have found that if pages are still displaying old versions, purging the cache now works. Will that eventually shake out or will it take someone visiting each page? If so, can that somehow be forced; to purge the cache of all pages (I'm sure that's expensive, but we're also a relatively low-traffic project, hence the pending closure)?

I just worked through several pages in the list linked below, and a single purge was enough to pull in the latest version of a given template. The articles included at the top of that list should all go away, as they should have been pointed to a different template (we shifted from template:infobox to template:infosection to migrate away from DPL).

https://en.wikinews.org/w/index.php?title=Special:WhatLinksHere/Template:Infobox&limit=500

These numbers (of pages using DPL) being accurate will really help our migration efforts, which should be completed before May 4, when the project is set to go read-only and DPL uninstalled from the project.

Thanks again to everyone helping out!

I know the ticket is closed as resolved and I'm not asking for it to be re-opened. I wanted to update the ticket for future awareness. I've found at least two problematic templates that persistently showed up in Category:Pages using the DynamicPageList extension despite having removed DPL. Other edits appeared properly.

Moving and rebuilding the the templates with copy/paste from old to new solved that problem. I'm not sure if its a DPL problem with the category or a FlaggedRevs problem, or a confluence of the two. The two templates, should anyone want to take a look, are:

• https://en.wikinews.org/wiki/Template:Hungary_(OLD)
• https://en.wikinews.org/wiki/Template:Bristol_(OLD)

Again, given the pending project closure, I am not asking for any assistance. Thanks again for everyone's help!

FWIW, that sounds to me like the kind of problem that a null edit might have solved as well. (Null edits are somewhat “stronger” than purges.)

Thanks. I actually made an actual edit (removing DPL) first. Then tried a purge (multiple times). Shouldn't that have done the same things as a null edit?

It should have, yes – that’s odd. I could imagine that the enwikinews job queue is relatively full on account of many templates and pages being affected by the deDPLification? But I don’t know, sorry.