Last modified: 2014-11-17 10:36:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6092 - Create colon parserfunction version of {{REVISIONID}}, {{REVISIONTIMESTAMP}} etc. that take pagename as parameter
Create colon parserfunction version of {{REVISIONID}}, {{REVISIONTIMESTAMP}} ...
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Low enhancement with 13 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-parsertest, patch, patch-reviewed
: 22687 48746 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-05-26 08:06 UTC by Trần Thế Trung
Modified: 2014-11-17 10:36 UTC (History)
25 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

add parser funtions {{REVISIONID:name}}, {{REVISIONDAY:name}}, {{REVISIONDAY2:name}}, {{REVISIONMONTH:name}}, {{REVISIONYEAR:name}}, {{REVISIONTIMESTAMP:name}} and {{REVISIONUSER:name}} (3.43 KB, patch)
2009-04-09 00:41 UTC, merl

Description Trần Thế Trung 2006-05-26 08:06:52 UTC

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.
2. 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
Comment 1 Nguyen Thanh Quang 2006-05-26 10:34:32 UTC

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

Comment 2 ALS 2006-05-26 13:09:35 UTC
Hi all,

I also think that this would be a helpful feature.

Comment 3 Minh Nguyễn 2006-05-26 15:46:06 UTC
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]].)
Comment 4 Phil Boswell 2006-05-26 15:48:01 UTC
Try investigating the rather spanking-new {{CURRENTTIMESTAMP}} variable...

Comment 5 Minh Nguyễn 2006-05-26 15:52:28 UTC
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.
Comment 6 Trần Thế Trung 2006-05-26 16:15:09 UTC
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}}, 
Comment 7 Minh Nguyễn 2006-05-26 16:19:46 UTC
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.
Comment 8 Trần Thế Trung 2006-05-26 18:19:27 UTC
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 
Comment 9 Danny B. 2006-06-14 01:05:15 UTC
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.
Comment 10 Duncan Harris 2006-09-26 14:41:49 UTC
This is an enhancement, but it should have high priority.
Comment 11 Jimmy Collins 2006-09-26 17:22:10 UTC
{{REVISIONYEAR}} and {{REVISIONTIMESTAMP}} have been introduced in r16659.
Comment 12 Danny B. 2006-09-26 18:14:25 UTC
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.
Comment 13 JePe 2006-10-03 19:36:06 UTC
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.
Comment 14 JePe 2006-10-31 20:34:27 UTC
I have found a workaround for this bug, for example when using {{REVISIONYEAR}}:

{{#ifeq: {{REVISIONYEAR}} | 1999 | {{CURRENTYEAR}} | {{REVISIONYEAR}} }}
Comment 15 darklama 2006-11-09 19:16:30 UTC
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.
Comment 16 FND 2007-04-10 16:47:22 UTC
Along those lines, I just noticed there's REVISIONDAY2 (leading zero), but no
Comment 17 Splarka 2008-01-06 02:13:44 UTC
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()".
Comment 18 Philippe Verdy 2008-11-14 00:09:36 UTC
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).

Comment 19 Philippe Verdy 2008-11-26 20:15:09 UTC
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!)
Comment 20 merl 2009-04-02 11:12:09 UTC
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]].
Comment 21 merl 2009-04-09 00:41:42 UTC
Created attachment 6008 [details]
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
Comment 22 Roan Kattouw 2009-04-16 21:47:59 UTC
Modified patch committed in r49575.
Comment 23 Melancholie 2009-04-17 05:26:12 UTC
@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:
Comment 24 Alexandre Emsenhuber [IAlex] 2009-04-17 06:42:00 UTC
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:}}.
Comment 25 Alexandre Emsenhuber [IAlex] 2010-03-02 16:30:55 UTC
Reopening bug; feature was reverted in r51424.
Comment 26 Alexandre Emsenhuber [IAlex] 2010-03-02 16:31:09 UTC
*** Bug 22687 has been marked as a duplicate of this bug. ***
Comment 27 Brian McNeil 2010-05-27 01:14:08 UTC
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 CountActive|portal={{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.
Comment 28 Brian McNeil 2010-05-27 01:26:57 UTC
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
Comment 29 Krinkle 2010-06-28 00:49:39 UTC
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:
Comment 30 Krinkle 2011-03-12 20:16:52 UTC
(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.
Comment 31 Sumana Harihareswara 2011-11-09 19:15:01 UTC
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!
Comment 32 Dereckson 2013-01-14 16:44:17 UTC
See also bug 43955.
Comment 33 db [inactive,noenotif] 2013-06-01 21:05:55 UTC
*** Bug 48746 has been marked as a duplicate of this bug. ***
Comment 34 Gerrit Notification Bot 2013-07-29 16:50:53 UTC
Change 76534 had a related patch set uploaded by Umherirrender:
Add expensive parser functions {{REVISION*:}}
Comment 35 Betacommand 2013-11-01 15:35:51 UTC
Can I get an update on this status?
Comment 36 Andre Klapper 2013-11-01 15:51:15 UTC
The link in comment 34 shows that nobody has reviewed the patch yet. 
That is the status.
Comment 37 Gerrit Notification Bot 2013-11-04 23:21:48 UTC
Change 76534 merged by jenkins-bot:
Add expensive parser functions {{REVISION*:}}
Comment 38 Umherirrender 2013-11-05 14:53:48 UTC
Now merged, so this should be fixed.
Will be part of 1.23

Note You need to log in before you can comment on or make changes to this bug.