Create colon parserfunction version of {{REVISIONID}}, {{REVISIONTIMESTAMP}} etc. that take pagename as parameter
Closed, ResolvedPublic


Author: tttrung


There is already {{REVISIONID}} variable for use in referencing (in URL). I wonder

These variables are useful in the following cases:

  1. In template that need the date of revision, especially those that deal

categorizing page by date of revision. One explicit example is template
{{somewebsite}} for image upload. If this has not been revised for 7 days, the image
is automatically categorized into the category for deletion.

  1. In referencing (more human understandable than REVISIONID).

Thank you for your support to this bug. If this bug is not necessary, as the above
cases can have other solution, please discuss them openly here.

Tran The Trung

Version: 1.8.x
Severity: enhancement
URL: for my bug
See Also:


bzimport set Reference to bz6092.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.May 26 2006, 8:06 AM

thanhquang.nguyen wrote:


I imagine when these variables are enabled, the users would bear less burden of
manually re-categorizing all the templates mentioned above.


als3r8 wrote:

Hi all,

I also think that this would be a helpful feature.


mxn added a comment.May 26 2006, 3:46 PM

I seem to remember a similar bug being filed, but I can't track it down. In any
event, the Cite.php extension that provides [[Special:Cite]] uses variables such
as {{CURRENTDAY}} and {{CURRENTMONTH}} within a <citation> tag, changing the
context so that these variables return the current day and month of the
specified revision. Perhaps this approach could be generalized. (See
[[MediaWiki:Cite text]].)

Try investigating the rather spanking-new {{CURRENTTIMESTAMP}} variable...


mxn added a comment.May 26 2006, 3:52 PM

That's nice, but it still requires us to use more than one template, like the
[[Template:Prod]] - [[Template:Dated prod]] combination at en:. This request is
intended to eliminate that need.

tttrung wrote:

I find this is exactly what we (or probably just me)
wanted; somehow I did not known about this before.

I think this will eliminate Prod - Dated prod - like
template, or at least a wide range of them.

Thanks and because of {{CURRENTTIMESTAMP}}, we
probably won't need {{REVISIONDAY}},

mxn added a comment.May 26 2006, 4:19 PM

Trung, I don't know how you plan to use it: if you purge [[vi:Wikipedia:Chỗ
thử]], for example, the timestamp changes according to the current time. It's no
different than using {{CURRENTYEAR}}, {{CURRENTMONTH}}, {{CURRENTTIME}}, and all
the rest.

tttrung wrote:

Minh is right. I thought {{CURRENTTIMESTAMP}} should
not change with time. However, it is currently no more
better than {{CURRENTYEAR}}, {{CURRENTMONTH}}, ...

Let's ignore my previous post and continue pushing for

Also {{REVISIONTIMESTAMP}} and {{REVISIONDAY2}} could be implemented as well.

I would also like to see all of them (including {{REVISIONID}}) with optional
either 1. {{REVISIONWHATEVER|pagename}}
or 2. {{REVISIONWHATEVER|I}} (say Include, or any other letter as you wish)

When I have some template of which I'd need to know the {{REVISIONWHATEVER}} -
when included in article it would show the revision-whatever of the article and
not of the template.

Concretely (nothing particular, just for illustration):
-article SomeCountry would look like this:
SomeCountry is somewhere over the rainbow... blah blah blah...
{{List of virtual countries}}

-template List of virtual countries would look like this:
List of virtual countries (last edit: {{REVISIONDAY}}. {{REVISIONMONTH}}.

  • ...


In current manner the list's last edit date on SomeCountry article would depend
on editing of SomeCountry article instead of {{List of virtual countries}}.

Therefore (see above):
either 1. allow to pass variable - some full page name of which we need to know
or 2. set some "magic parameter" to declare we need revision-whatever of its
source but not of the final result page

Sorry, if it sounds too complicated, but I hope it will be clear what I meant.

dunc_harris wrote:

This is an enhancement, but it should have high priority.

jimmy.collins wrote:

{{REVISIONYEAR}} and {{REVISIONTIMESTAMP}} have been introduced in r16659.

Reopening to ask for feature described in comment #9 - particulary the
{{REVISIONwhatever|<pagename>}} with adding more ideas below.

{{REVISIONtimeformat}} alone is just duplicate of info written in footer.

I wouldn't support this bug if it was only question of simple adding of these
magic words. I was hoping, that the additional functionality will be included as

If confusing syntax as magic word, please consider colon/parser function such as eg.
*{{lastrevision:<pagename>}} - can output timestamp which can be passed to
*{{#lastrevision:<pagename>|<format string for date()>}}
*{{revisiontime:<revisionid>}} - can output timestamp which can be passed to
*{{#revisiontime:<revisionid>|<format string for date()>}}

There are very useful cases when it's necessary to know the last revision time
of some page and currently there's no way to get it. And sometimes is useful to
know the revision time of past revisions.

Thanks in advance.

jepe wrote:

When I'm editing an article on nl.wikipedia with has the magic word
{{REVISIONYEAR}}, it displays as 1999 (only during the page preview). Also when
I use it for the name of a category, the article is categorized with 1999 in the
categoryname instead of 2006, although the category is showing 2006 after saving
the article.

I think it's better that all {{REVISION....}} magic words will display the
content of the same {{CURRENT....}} magic words during an edit and a page preview.

jepe wrote:

I have found a workaround for this bug, for example when using {{REVISIONYEAR}}:

{{#ifeq: {{REVISIONYEAR}} | 1999 | {{CURRENTYEAR}} | {{REVISIONYEAR}} }}

darklama wrote:

There is already {{CURRENTTIME}} and {{CURRENTHOUR}}. {{CURRENTMINUTE}},
{{REVISIONTIME}}, {{REVISIONHOUR}} and {{REVISIONMINUTE}} seem to be missing. I
also agree there needs to be a way to get the revision information of other
pages. I also think there needs to be an easy way to determan what a page name
or part of a page name should be given a name. Something like:

{{BASEPAGENAME:Help:Docs/Magic_words}} -> Docs
{{SUBPAGENAME:Help:Docs/Magic_words}} -> Magic_words
{{NAMESPACE:Help:Docs/Magic_words}} -> Help
{{TALKPAGE:Help:Docs/Magic_words}} -> Help_Talk
{{TALKPAGENAME:Help:Docs/Magic words}} -> Help_Talk:Docs/Magic_words

with the default value being the current page name, allowing backwords
compatibility to be maintained with existing templates.

a good example of how this would be useful is a merge template to mark two pages
that someone thinks should be merged in which it provides a link to a single
discussion in which the two pages are not in the same namespace. There are some
easy "tricks" for doing it when they are in the same namespace, that are
currently used on a project, but which falls apart of the pages are not in the
same namespace.

fdg001 wrote:

Along those lines, I just noticed there's REVISIONDAY2 (leading zero), but no

herd wrote:

These have an interesting bug, FYI.

Compare for example, creating a page with {{subst:REVISIONTIMESTAMP}} and {{REVISIONTIMESTAMP}}. The numbers should match. However, if you perform a null edit, the REVISIONTIMESTAMP will update to the date of the null edit. Also of interest, if you action=purge the page, the REVISIONTIMESTAMP goes back to match the previous subst'd number, giving unpredictable results. Note that this problem doesn't seem to exist with {{REVISIONID}} as there is no revision registered with a null edit or purge.

Perhaps these should use something akin to what the lastModified() function uses, eg "$wgArticle->getTimestamp()", instead of "getTouched()".

Oh, I forgot to say that my proposal contains enough provisions to avoid the multiplication of "{{MAGICTEMPLATES}}" that are creating collisions with normal templates. It can be used also to expose all sorts of server-side variables (in the core engine, or in one of its plugins), either to get their values, or set them if the namespace in which they are defined is left modifiable by the server.

My proposed extension also gives a solution about the difficulties to write our most complex templates that are also the most useful and widely used, but absolutely horrible to understand (because it would deprecate completely the use of the current "too many braces embedded" style).

My proposal can in fact avoid as well the creation of MANY MediaWiki extensions to handle tricky cases that the curernt template syntax cannot handle gracefully ; it is powerful enough to allow MediaWiki to become a true programming language, object oriented as well, except that there will be only attributes with no exposed methods (in fact, just two methods are needed: "get" and "set", "get" being the default method or action, but this is extensible to other actions like "push" and "pop" and to manage, in a context variable, an array/list of values, something that existing templates parameters cannot manage easily).

Please ignore my comment above, it was noramlly an additional comment to another bug (I forgot to come back to the bug id I was replying to. Unfortunately, Bugzilla moves to another bug when replaying to one, and does not let us see our post in the bug id thread where it was posted (and we don't necessarily want to go to some other arbitrary bug id!)

Merl added a comment.Apr 2 2009, 11:12 AM

I would also like to have the feature of getting revision information from another page as mentioned in #c9 and #c15. This feature is implemented for all other page-dependant magic words like {{TALKPAGENAME:Main Page}}, etc. in [[rev:46662]] by [[Bug:8249]].

Merl added a comment.Apr 9 2009, 12:41 AM

Created attachment 6008
add parser funtions {{REVISIONID:name}}, {{REVISIONDAY:name}}, {{REVISIONDAY2:name}}, {{REVISIONMONTH:name}}, {{REVISIONYEAR:name}}, {{REVISIONTIMESTAMP:name}} and {{REVISIONUSER:name}}

patch adds parser funtions as i requested in comment #20

Attached: Revision_Parser_Functions.patch

Modified patch committed in r49575.

Wiki.Melancholie wrote:

@Roan Kattouw: Could it be that we now have a magic word called {{REVISIONUSER}} and a parser function called {{REVISIONUSER:}}?

See bug 10336.


Redundant, I think:

IAlex added a comment.Apr 17 2009, 6:42 AM

We already have both variable and parser function with the same name, e.g. {{PAGENAME}} (see r46662).
They are not redundant, since the variable will handle only {{REVISIONUSER}} and the parser function will only be called if there's a colon, such as {{REVISIONUSER:}}.

IAlex added a comment.Mar 2 2010, 4:30 PM

Reopening bug; feature was reverted in r51424.

IAlex added a comment.Mar 2 2010, 4:31 PM
  • Bug 22687 has been marked as a duplicate of this bug. ***

brian.mcneil wrote:

This, if I read correctly, is something Wikinews would very much like to have.

Many, many of our portal pages would - ideally - have portal-specific leads, but if the contributor(s) maintaining these pages leave, we would want the portal pages to vanish once they were about a week old.

We would thus have:

[[Portal:Eurasia/Lead 1]]
[[Portal:Eurasia/Lead 2]]
... and so on.

In [[Portal:Eurasia]], the following is a simplification of the code required:


currentleads={{PortalTemplate CountActiveportal={{FULLPAGENAME}}}}

In [[Template:PortalTemplate]], the *lower of leads or currentleads dictates how many leads displayed at the top of the page.

In [[Template:PortalTemplate CountActive]], some sort of code to
{{REVISIONTIMESTAMP:{{portal}}/Lead 1}} is value within 7 days, add one
{{REVISIONTIMESTAMP:{{portal}}/Lead 2}} is value within 7 days, add one
{{REVISIONTIMESTAMP:{{portal}}/Lead 3}} is value within 7 days, add one

I think en.wikinews has everything else needed, and I know we've been happy to be experimented on before. I'm going to ask a couple of our more techie people to look, comment, and hopefully vote.

brian.mcneil wrote:

Actually, re-reading the full above discussion, and considering some of the comments' age, I'd be looking at using:


Do some math to sum up all the {{/Lead <1..5>}} that are less than a week old, and our portals would degrade gracefully instead of leaving years-old leads up following a reporter being killed off. :P

The ability to show the REVISIONTIMESTAMP of for example a Template would very much ease up several things on wikipedia.

Currently the comment in the r51424 revert refers to:

(In reply to comment #29)

The ability to show the REVISIONTIMESTAMP of for example a Template would very
much ease up several things on wikipedia.

What I meant here is this:

say a Template is regularly updated with a certain value. {{REVISIONTIMESTAMP}} will show when it was last updated, but when the template is transcluded it'll show the revison timestamp of the host page.

A parameter to {{REVISIONTIMESTAMP}} wil enable to show the timestamp the template was last modified, regardless of how it was transcluded (and would not require transclusion at all).

Updating summary.

sumanah wrote:

I'm adding the "reviewed" keyword here -- merl, if that's not right, and there should be additional discussion and suggestion on how to revise the patch, please remove "reviewed" and add "need-review". And if you have time and interest in revising your patch against current trunk, please let us know and come into #mediawiki on freenode IRC to talk about it. Thanks!

See also bug 43955.

  • Bug 48746 has been marked as a duplicate of this bug. ***

Change 76534 had a related patch set uploaded by Umherirrender:
Add expensive parser functions {{REVISION*:}}

Can I get an update on this status?

The link in comment 34 shows that nobody has reviewed the patch yet.
That is the status.

Change 76534 merged by jenkins-bot:
Add expensive parser functions {{REVISION*:}}

Now merged, so this should be fixed.
Will be part of 1.23

mxn added a subscriber: mxn.Nov 24 2014, 8:52 PM

Add Comment