Last modified: 2009-02-23 09:03:48 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 12694 - {{subst:REVISIONID}} doesn't work
{{subst:REVISIONID}} doesn't work
Status: RESOLVED DUPLICATE of bug 6181
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.12.x
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/User:Kal...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-19 19:13 UTC by Kalan
Modified: 2009-02-23 09:03 UTC (History)
5 users (show)

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


Attachments

Description Kalan 2008-01-19 19:13:15 UTC
Test it on the page above — if you save it, no matter whether you've actually edited something or not, you will receive an empty space instead of {{REVISIONID}}; the only way to recover it is to do a purge.

This might be confusing for some places where {{REVISIONID}} is actually used, especially in combination with parser functions that distinguish preview and saved page this way.
Comment 1 MER-C 2008-02-18 07:15:55 UTC
Works for me. However, using {{subst:REVISIONID}} does result in permanent empty space, see [[WP:VPT#Using subst with REVISIONID]].
Comment 2 Roan Kattouw 2008-02-18 14:30:10 UTC
(In reply to comment #1)
> Works for me. However, using {{subst:REVISIONID}} does result in permanent
> empty space, see [[WP:VPT#Using subst with REVISIONID]].
> 

{{subst:REVISIONID}} is very tough because of the way we create revisions:

1. An entry in the text table containing the revision's text is created
2. The ID of the newly created entry is obtained
3. An entry in the revision table is created, referencing the text table entry by the ID obtained in #2
4. The revision ID of the newly created revision is obtained
5. The page_latest field of the page's entry in the page table is set to the new revision ID

It's easy to see that the text has to be known before the revision is created, so the new revision ID isn't known at that time. A possible solution would be to go back and replace any occurrences of {{subst:REVISIONID}} in the text entry after creating the revision, but that would be hacky and possibly expensive.
Comment 3 Kalan 2008-02-18 14:38:46 UTC
> It's easy to see that the text has to be known before the revision is created

Not really. I can't remember whether this has been proposed anywhere, but anyway it's pretty possible to substitute the top revid of the page before saving.

Then, you will be able to make "prooflinks" such as {{fullurl:{{FULLPAGENAME}}|diff=next&oldid={{subst:REVISIONID}}}} (that's possibly the main purpose of this substitution).
Comment 4 Roan Kattouw 2008-02-18 14:42:03 UTC
(In reply to comment #3)
> > It's easy to see that the text has to be known before the revision is created
> 
> Not really. I can't remember whether this has been proposed anywhere, but
> anyway it's pretty possible to substitute the top revid of the page before
> saving.
> 

That would give you the revid of the revision just before yours (the 'previous' revision, if you like). Assigning this behavior to {{subst:REVISIONID}} would create a discrepancy with {{REVISIONID}}. Of course {{PREVREVID}} or something similar could be implemented.
Comment 5 Nathan Larson 2008-02-19 01:57:44 UTC
Perhaps there could be a workaround? What if there were a magic word for the next REVISIONID in a page history after the last REVISIONID? I.e., as I'm editing (or as I'm saving, whichever the case may be), I know that the previous REVISIONID for that page was 314159265. So, I save it with this new magic word, and it knows that on a permanent basis, it is supposed to display the next REVISIONID in the page history after 314159265. A potential issue with this, I guess, is that what if someone saves another version with a different REVISIONID while you're editing? Would that be a problem? (Cross-posted to WP:VPT)
Comment 6 Happy-melon 2008-10-03 17:32:34 UTC
(In reply to comment #2)
> ... A possible solution would be
> to go back and replace any occurrences of {{subst:REVISIONID}} in the text
> entry after creating the revision, but that would be hacky and possibly
> expensive.
> 

Not that expensive, surely? Naturally you'd do a check for that string *before* you saved it, and only do the extra db transaction to substitute it if it was actually there.  What percentage of page saves do you think include that magic word? :-D And I guess it is a little bit hacky, but not offensively so.  

(In reply to comment #5)
>Perhaps there could be a workaround? What if there were a magic word for the
>next REVISIONID in a page history after the last REVISIONID? I.e., as I'm
>editing (or as I'm saving, whichever the case may be), I know that the previous
>REVISIONID for that page was 314159265. So, I save it with this new magic word,
>and it knows that on a permanent basis, it is supposed to display the next
>REVISIONID in the page history after 314159265. A potential issue with this, I
>guess, is that what if someone saves another version with a different
>REVISIONID while you're editing? Would that be a problem? 

Eh? What use would that be? {{NEXTREVISIONID}} would be constantly undefined (by definition, unless we totally change the way we assign ids), and {{subst:NEXTREVISIONID}} is a different way of restating the same problem, while entrenching the mentality of "revision id is defined only after page saves", which is unavoidable from the db structure but still unhelpful.  
Comment 7 Mike.lifeguard 2008-10-03 17:39:24 UTC
I think this summary is describes more accurately the real problem.
Comment 8 Anon Sricharoenchai 2009-02-23 09:03:48 UTC

*** This bug has been marked as a duplicate of bug 6181 ***

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


Navigation
Links