Page MenuHomePhabricator

REVISIONID cannot be substituted
Closed, DeclinedPublic

Description

Author: omniplex

Description:
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".


Version: 1.7.x
Severity: normal
Platform: Other
URL: http://meta.wikimedia.org/wiki/Help:Variable#Depending_on_revision

Details

Reference
bz6181

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:20 PM
bzimport set Reference to bz6181.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

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).

omniplex wrote:

Okay, the unusual behaviour is documented on
[[m:Help:Variable]] and [[m:Help:Substitution]].
Maybe simply tag it with "WONTFIX".

anon.hui wrote:

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

anon.hui wrote:

*** 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.

joshua.scott wrote:

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 {

    1. *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.