In T137900#5079322, @gerritbot wrote:

Change 294774 merged by jenkins-bot:
[mediawiki/core@master] Disable expensive {{REVISIONID}} magic word in miser mode

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

Change 527125 had a related patch set uploaded (by Krinkle; owner: Aaron Schulz):
[mediawiki/core@master] parser: further restrict "revisionid" by namespace in $wgMiserMode

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

After investigating some weird #expr error with {{REVISIONID}} that I couldn't reproduce in my sandbox, I eventually found out about this change and updated mw:Help:Magic words and mw:Manual:$wgMiserMode to the best of my understanding.

It would have been nice if this change had been announced on Tech News, especially because of the namespace-dependent behaviour.

Thanks @Bdijkstra, changes like these should indeed be announced. I'm sorry we didn't reach you. The change was announced in Tech News (2019, week 15) (see also T137900#5087023)

I'm tagging User-notice here as well as reminder for Parsing Team to include an item in Tech News for the next phase as well.

But that would be later?

My apologies, indeed it was mentioned in TN and that issue was posted on a page that I follow. I just didn't look far enough into the past. Still, I think it should have been documented on the mentioned manual pages and also in the release notes.

@Krinkle I've been reading mw:Manual:$wgMiserMode but to make sure I don't misunderstand anything: compared to the original announcement, is there anything that should be added except "in wgMiserMode"?

@Johan Aye, that's a red-herring. The previous change we rolled out was already conditional on wgMiserMode. The "Miser mode" of MediaWiki is basically a "Big farm" mode. It is enabled on all WMF wikis.

In April 2019 this change was applied to pages in "content namespaces".

The upcoming change here will apply the change to the File and Category namespaces. (date still TBD, will let Parsing Team answer that.)

After that, a final change (likely, but not yet certain) will be to apply it to all namespaces (still only for WMF wikis / Miser mode - not MW default install configuration).

Noted. A good example of why I always ask. (: I'll add it to the newsletter going out on Monday as on early heads-up.

@Krinkle, is there anything more for us (parsing-team) to be aware of here beyond the fact that it is just rolling out to other namespaces? I am happy for you to roll this out whenever you are ready for it. But looks like the train is stalled now anyway and we are soon coming up to the holiday break. Does early Jan look like a good time for this? Or do you want to fold in to the next deploy?

I'll land it in January. Thanks.

Change 527125 merged by jenkins-bot:
[mediawiki/core@master] parser: further restrict "revisionid" by namespace in $wgMiserMode

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

Change 570985 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] parser: apply $wgMiserMode restriction to REVISIONID for NS_USER/NS_PROJECT

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

Change 570986 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] parser: apply $wgMiserMode restriction to self-referencial {{REVISIONID|}}

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

Change 570985 merged by jenkins-bot:
[mediawiki/core@master] parser: apply $wgMiserMode restriction to REVISIONID for NS_USER/NS_PROJECT

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

Change 570986 merged by jenkins-bot:
[mediawiki/core@master] parser: apply $wgMiserMode restriction to self-referencial {{REVISIONID|}}

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

Can I ask what purpose is served by {{REVISIONID}}? With the disabling of this feature, which was the ONLY useful application of this magic word, there is absolutely no practical use for {{REVISIONID}} that I can envision, so you all might just as well remove {{REVISIONID}} from large wikis entirely. No point in documenting something that has no practical use.

Oh, I see: "Preview detection"
The most common use case for {{REVISIONID}} is to detect preview mode. This will not be broken.

How do you do that? Where is it documented?

In T235957#5927007, @Wbm1058 wrote:

The most common use case for {{REVISIONID}} is to detect preview mode. This will not be broken.

How do you do that? Where is it documented?

Documented at mw:Help:Magic words#REVISIONID. Some templates use it, see for example Template:If preview (Q25954383).

Thanks, but this link https://en.wikipedia.org/wiki/Template:If_preview is more helpful. My understanding is that the test can only be done using a Lua module; all the template does is invoke the Lua module.

What is more helpful depends on your language skills, which I don't presume to know. Also I hadn't realised that most variations use a Lua module; I have no idea why they would do that, as it can be done with a single template expression, which the //nl// version does.

Why does {{REVISIONID}} now return blank when substed? Shouldn't it at least return '-'?

What is the accommodation for cases where the revision ID needs to be inserted into a URL such as in Template:Db-g12 or Template:RMassist/core?

In T235957#5927239, @Wbm1058 wrote:

Thanks, but this link https://en.wikipedia.org/wiki/Template:If_preview is more helpful. My understanding is that the test can only be done using a Lua module; all the template does is invoke the Lua module.

{{#if:{{REVISIONID}}|Not preview|Preview}} appears to work without Lua.

Since this is the remaining open task for REVISIONID for preview indicator things, I'm just going to leave a note here that I closed T53660: Detect the edit state for modules which help users and helpers invalid, which has been open some time. Not entirely sure that was the best thing to do, but it seems like it.

In T235957#5927586, @Ahecht wrote:

Why does {{REVISIONID}} now return blank when substed? Shouldn't it at least return '-'?

What is the accommodation for cases where the revision ID needs to be inserted into a URL such as in Template:Db-g12 or Template:RMassist/core?

I created a bot as my solution for Template:RMassist/core, after a light bulb turned on in my head. The "migration guide" wasn't that much help.

Right, I understand my bot is sort of a hack. It doesn't strike me as "miserly" to keep making null edits on the chance the page might have been edited, and thus have a new revision ID. But apparently this is still more miserly than the way things worked before "miser mode" was implemented. If anyone has a better solution, I'm open to that.

What's the issue that still needs fixed? I don't understand why this is still open. What difference does it make whether {{REVISIONID}} is a number or "-"? Why not keep the number? I hope this task doesn't break my bot task if its implemented.

I don't think this task will break Bot1058, because it only effects getting the revision ID of the current page. The reason that the ability to do that is problematic is that, under normal circumstances, the wikitext of a new revision is parsed before assigning an ID to that revision for performance reasons, and {{REVISIONID}} thus forces the page to be parsed again.

This task remains open as there remain more scenarios in which {{REVISIONID}} still behaves the old/expensive way, which are yet to be converted still.

As of writing in December 2020, the new miser mode has been applied to all "subject" namespaces. It was originally applied to the main namespace only, and extended to content namespaces, and then most recently to subject namespaces. What remains is applying it to talk namespaces (which is still TODO). The old behaviour is also still applies to interface messages, where it would make sense for consistency to apply this as well. However it is not a priority there for performance, so that could wait until we're sure any reliance on it there can be and has been migrated to more performant solutions to their underlying needs.