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.
Version: 1.12.x
Severity: normal
URL: http://en.wikipedia.org/wiki/User:Kalan/12694
Works for me. However, using {{subst:REVISIONID}} does result in permanent empty space, see [[WP:VPT#Using subst with REVISIONID]].
(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:
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.
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).
(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.
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)
happy_melon wrote:
(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.
mike.lifeguard+bugs wrote:
I think this summary is describes more accurately the real problem.