Last modified: 2014-09-21 20:57:07 UTC
At the moment #{{subst:REVISIONID}}# gives ## (empty string). If {{REVISIONID}} can only display the current revision it's pointless, the history / permalink mechanisms already support this. {{fullurl:{{FULLPAGENAME}}|oldid={{subst:REVISIONID}}}} is an example, where a substituted old revision ID could make sense, e.g. for a talk page "archive".
Right now, it's impossible to substitute this magic word, since a revision id hasn't been assigned during the pre-save transform (nor should one be, since the PST is used in more places than just saving page content).
Okay, the unusual behaviour is documented on [[m:Help:Variable]] and [[m:Help:Substitution]]. Maybe simply tag it with "WONTFIX".
*** Bug 11964 has been marked as a duplicate of this bug. ***
*** Bug 12694 has been marked as a duplicate of this bug. ***
*** Bug 23876 has been marked as a duplicate of this bug. ***
c2 says WONTFIX, so I am changing status from LATER to WONTFIX.
*** Bug 69138 has been marked as a duplicate of this bug. ***
Possibly for consistency we could disable subst:'ing of the rest of the revision-time information magic words – REVISIONDAY, REVISIONDAY2, REVISIONMONTH, REVISIONYEAR, REVISIONMTIMESTAMP, REVISIONUSER?
Or, instead of potentially breaking who-knows how many templates and wikis that may be using subst: on those other magic words, you could leave them alone and get consistency in behaviour by fixing the issue with REVISIONID instead, which is what people actually want? This issue has been raised many times, and there are various forum threads on the internet where people are asking how to use subst: for REVISIONID. At the moment it simply is not possible.
(In reply to GregH from comment #9) > Or, instead of potentially breaking who-knows how many templates and wikis > that may be using subst: on those other magic words, People using bad parts of MediaWiki should always beware that it's likely we stop supporting hacks that shouldn't work. This has always been the case. The fact that the faked-in (not real) versions of REVISIONMTIMESTAMP are made available is ludicrous. > you could leave them > alone and get consistency in behaviour by fixing the issue with REVISIONID > instead, which is what people actually want? > > This issue has been raised many times, and there are various forum threads > on the internet where people are asking how to use subst: for REVISIONID. At > the moment it simply is not possible. Umm… The fabric of the universe prevents this request, as anyone who understands how MediaWiki works could immediately spot. There is no possible way you can know the ID until after you've inserted it, at which point you can't change what you've just inserted without changing the revision ID, at which point the ID you inserted isn't the ID for the content you want, at which point… etc.. This is not "WONTFIX" from evil, laughing developers who don't care. It's "REALITY INTERJECTS".
I'm not suggesting we put in the revision ID for the current edit in-progress, I understand that is difficult and not going to be fixed. So, do the next best thing: put in the revision ID for the latest stable edit. That is how all of the other magic words already work. What's worse, saying: 1. subst:REVISIONID will not do anything at all 2. subst:REVISIONID will give you the ID of the current stable revision, not the one you are in progress of making #1 is useless and nothing can be done with it. #2 is useful and the limitations can be understood. All of the other REVISION magic words already do #2.
Here is a patch to fix the issue seen by GregH, using his suggested fix. Note: If {{subst:REVISIONID}} is used on a newly created page, the string "Initial Revision" will be used in place of a revision number. diff --git a/includes/parser/Parser.php b/includes/parser/Parser.php index 10765de..a8c6dd7 100755 --- a/includes/parser/Parser.php +++ b/includes/parser/Parser.php @@ -2761,7 +2761,9 @@ class Parser { # *after* a revision ID has been assigned. $this->mOutput->setFlag( 'vary-revision' ); wfDebug( __METHOD__ . ": {{REVISIONID}} used, setting vary-revision...\n" ); - $value = $this->mRevisionId; + $value = $this->mRevisionId; + if ($value == "") + $value = $this->tryGetRevisionId(); break; case 'revisionday': # Let the edit saving system know we should parse the page @@ -5517,6 +5519,17 @@ class Parser { return $this->mRevisionTimestamp; } + /** + * This code is to enable {{subst:REVISIONID}}. It will use the + * previous revision ID if it is available. If this is a new + * page being saved for the first time, the string "Initial + * Revision" will be used instead. + */ + function tryGetRevisionId() { + $rev = Revision::newFromTitle ($this->mTitle); + return $rev ? $rev->getId() : "Initial Revision"; + } + /** * Get the name of the user that edited the last revision *
(In reply to James Forrester from comment #8) > Possibly for consistency we could disable subst:'ing of the rest of the > revision-time information magic words – REVISIONDAY, REVISIONDAY2, > REVISIONMONTH, REVISIONYEAR, REVISIONMTIMESTAMP, REVISIONUSER? We don't need to do that, because those ones do the right thing when substed. (In reply to GregH from comment #11) > So, do the next best thing: put in the revision ID for the latest stable > edit. That is how all of the other magic words already work. > > What's worse, saying: > 1. subst:REVISIONID will not do anything at all > 2. subst:REVISIONID will give you the ID of the current stable revision, not > the one you are in progress of making > > #1 is useless and nothing can be done with it. #2 is useful and the > limitations can be understood. > > All of the other REVISION magic words already do #2. The other ones don't do #2; they actually do return the values of the new revision. (In reply to Joshua Scott from comment #12) > Here is a patch to fix the issue seen by GregH, using his suggested fix. Please submit patches to gerrit rather than posting them here.
Well, so much for "the fabric of the universe" meaning there was "no possible way" to fix this bug.
