A brilliant idea. Indeed, this would be very useful.

I think all revision variables should be removed, and none more added. They double the page save time, which can run into tens of seconds on large pages.

Perhaps it would make sense to move these parameters out of core into an extension. Since I believe that a lot of people are using them this might be a good idea if possible. Sadly I cannot evaluate this.

Just wondering, why would this be useful? Personally I can't think of a reason to need the timestamp of a specific revision specified by a specific id. I can see having the info for current revision as useful, but for other revisions?

stuart wrote:

(In reply to comment #4)

Just wondering, why would this be useful? Personally I can't think of a reason
to need the timestamp of a specific revision specified by a specific id. I can
see having the info for current revision as useful, but for other revisions?

Say you have a page whose content is reflected elsewhere (such as a wikipage describing a blueprint for a technical system). You can make a template that takes the revision ID of the last revision that was current with the system, which displays a link to that revision and how long ago it was written.

Another use case is the deletion templates, which could use {{REVISIONUSER:1}} to link directly to the user who created the page so they can be notified.

However, bug 23427 comment #13 indicates that retrieving this info is an expensive operation. If this means that this request will never be implemented, then someone please close this bug as WONTFIX so we can reallocate our hope credits to other items in our wishlists :)

See also bug 23427 comment 15. Aside from being expensive, 'what is to be considered the "first" revision' is also an open issue. (timestamp, revision id, hidden/visible, history merges, imports)

Well, if any of those actions is performed on a page, these revision magic words could simply return an error (assuming undefined?) if a parameter larger than 0 is passed. {{#iferror:}} can then be used to deal with this.

In any case, the simpler use cases for the first revision (speedy deletion for instance) usually don't involve such complex page manipulation, so the potential benefit outweighs the edge cases where this would fail.

a.d.bergi wrote:

If this is going to be implemented, I would stronlgy suppose to make the index parameter a _parameter_ and not a function argument:

{{REVISON...:[page name]|[relative revision index]}}

as per Bug 6092#c15