Last modified: 2014-11-17 10:36:18 UTC
Hello, There is already {{REVISIONID}} variable for use in referencing (in URL). I wonder if we could have {{REVISIONDAY}}, {{REVISIONMONTH}}, {{REVISIONYEAR}}. 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
Hello, I imagine when these variables are enabled, the users would bear less burden of manually re-categorizing all the templates mentioned above. Regards, Quang
Hi all, I also think that this would be a helpful feature. Regards.
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... HTH HAND
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.
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}}, {{REVISIONMONTH}}, {{REVISIONYEAR}} anymore.
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.
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 {{REVISIONDAY}}, {{REVISIONMONTH}}, {{REVISIONYEAR}}.
Also {{REVISIONTIMESTAMP}} and {{REVISIONDAY2}} could be implemented as well. I would also like to see all of them (including {{REVISIONID}}) with optional parameter: either 1. {{REVISIONWHATEVER|pagename}} or 2. {{REVISIONWHATEVER|I}} (say Include, or any other letter as you wish) Example: 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}}. {{REVISIONYEAR}}) *SomeCountry *SomeOtherCountry * ... *YetAnotherCountry 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 revision-whatever 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.
This is an enhancement, but it should have high priority.
Magic words {{REVISIONDAY}}, {{REVISIONDAY2}, {{REVISIONMONTH}}, {{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 well. If confusing syntax as magic word, please consider colon/parser function such as eg. *{{lastrevision:<pagename>}} - can output timestamp which can be passed to {{#time:}} *{{#lastrevision:<pagename>|<format string for date()>}} and/or *{{revisiontime:<revisionid>}} - can output timestamp which can be passed to {{#time:}} *{{#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.
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.
I have found a workaround for this bug, for example when using {{REVISIONYEAR}}: {{#ifeq: {{REVISIONYEAR}} | 1999 | {{CURRENTYEAR}} | {{REVISIONYEAR}} }}
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.
Along those lines, I just noticed there's REVISIONDAY2 (leading zero), but no REVISIONMONTH2...
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!)
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]]. So it should also be implemented for {{REVISIONID}}, {{REVISIONDAY}}, {{REVISIONDAY2}}, {{REVISIONMONTH}}, {{REVISIONYEAR}}, {{REVISIONTIMESTAMP}} and {{REVISIONUSER}}
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
Modified patch committed in r49575.
@Roan Kattouw: Could it be that we now have a magic word called {{REVISIONUSER}} and a parser function called {{REVISIONUSER:}}? See bug 10336. Compare: 1. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/48149 2. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49575 Redundant, I think: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/MagicWord.php?view=log
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:}}.
Reopening bug; feature was reverted in r51424.
*** Bug 22687 has been marked as a duplicate of this bug. ***
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]] [[Portal:Eurasia/Lead 1]] [[Portal:Eurasia/Lead 2]] ... and so on. In [[Portal:Eurasia]], the following is a simplification of the code required: {{PortalTemplate|topic=Eurasia |leads=5 |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 returnvalue= {{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.
Actually, re-reading the full above discussion, and considering some of the comments' age, I'd be looking at using: {{CURRENTTIMESTAMP:{{FULLPAGENAME}}/Lead <x>}} 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: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49575#c2356
(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.
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*:}} https://gerrit.wikimedia.org/r/76534
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*:}} https://gerrit.wikimedia.org/r/76534
Now merged, so this should be fixed. Will be part of 1.23
