Last modified: 2014-09-21 20:57:07 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 6181 - REVISIONID cannot be substituted
REVISIONID cannot be substituted
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
1.7.x
Other All
: Lowest normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Help:V...
:
: 11964 12694 23876 69138 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-03 03:58 UTC by omniplex
Modified: 2014-09-21 20:57 UTC (History)
10 users (show)

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


Attachments

Description omniplex 2006-06-03 03:58:28 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".
Comment 1 Rob Church 2006-06-12 11:38:53 UTC
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).
Comment 2 omniplex 2006-06-15 07:18:23 UTC
Okay, the unusual behaviour is documented on 
[[m:Help:Variable]] and [[m:Help:Substitution]].
Maybe simply tag it with "WONTFIX".
    
Comment 3 Anon Sricharoenchai 2009-02-23 08:06:42 UTC
*** Bug 11964 has been marked as a duplicate of this bug. ***
Comment 4 Anon Sricharoenchai 2009-02-23 09:03:48 UTC
*** Bug 12694 has been marked as a duplicate of this bug. ***
Comment 5 Alexandre Emsenhuber [IAlex] 2010-06-10 15:26:38 UTC
*** Bug 23876 has been marked as a duplicate of this bug. ***
Comment 6 Diederik van Liere 2011-11-29 21:41:44 UTC
c2 says WONTFIX, so I am changing status from LATER to WONTFIX.
Comment 7 Andre Klapper 2014-08-05 11:02:18 UTC
*** Bug 69138 has been marked as a duplicate of this bug. ***
Comment 8 James Forrester 2014-08-05 13:58:05 UTC
Possibly for consistency we could disable subst:'ing of the rest of the revision-time information magic words – REVISIONDAY, REVISIONDAY2, REVISIONMONTH, REVISIONYEAR, REVISIONMTIMESTAMP, REVISIONUSER?
Comment 9 GregH 2014-08-05 20:21:25 UTC
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.
Comment 10 James Forrester 2014-08-05 21:01:05 UTC
(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".
Comment 11 GregH 2014-08-05 21:32:05 UTC
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.
Comment 12 Joshua Scott 2014-08-19 04:53:47 UTC
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
         *
Comment 13 Jackmcbarn 2014-09-20 18:44:27 UTC
(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.
Comment 14 GregH 2014-09-21 20:57:07 UTC
Well, so much for "the fabric of the universe" meaning there was "no possible way" to fix this bug.

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


Navigation
Links