svippy wrote:

FST? That's the strangest abbreviation for 'first' I have ever seen, what's wrong with FIRST? You only saved 2 characters. Woah.

I'm more curious as to what the possible use case is for this.

svippy wrote:

Uhm. Okay, consider this. You, for some reason, want to link to the first revision of a page to make some sort of point.

No wait, that makes no sense, because then you could just use the history and make a static link.

Oh wait, I got it, it's for a template. That you can supply to pages, so like 'this is how it looked way back then, pretty bad eh?', followed by 'now check this shit out:'

Uhm, maybe if you were high. Or maybe the opposites of all features are automatically useful for some reason.

I am hoping the reporter will set me straight in this matter. Maybe I'm just an idiot who can't see this genius.

@Svip I must apologise for not being a native English speaker. I will try to
improve and widen my knowledge of the English language. A different name for
this proposed magic word is mostly welcome and ok with me.

@Chad H. I do not see a possible use for this on Wikimedia projects or
MediaWiki itself. However on third-party projects utilising the extension
Semantic MediaWiki it is quite useful if you need a unique number for a page
which does not change in the course of editing. To use the name of a page is
not useful since this is variable. It would serve as a very good reference and
makes querying easier.

@Svip You just made me to chuck up. Again I have to apologise to you.

(In reply to comment #4)

@Chad H. I do not see a possible use for this on Wikimedia projects or
MediaWiki itself. However on third-party projects utilising the extension
Semantic MediaWiki it is quite useful if you need a unique number for a page
which does not change in the course of editing. To use the name of a page is
not useful since this is variable. It would serve as a very good reference and
makes querying easier.

{{PAGEID}} would serve that purpose just fine, but I don't believe it exists.

svippy wrote:

(In reply to comment #5)

@Svip You just made me to chuck up. Again I have to apologise to you.

Don't apologise to me, I am just curious about this use.

(In reply to comment #6)

{{PAGEID}} would serve that purpose just fine, but I don't believe it exists.

In addition, since Semantic MediaWiki is an extension, shouldn't it be capable of obtaining this data itself? Or am I completely misunderstanding the workings of Semantic MediaWiki.

M8R-cyc3n3 wrote:

Oh wait, I got it, it's for a template. That you can
supply to pages, so like 'this is how it looked way
back then, pretty bad eh?', followed by 'now check this
shit out:'

i think the most common use would be to see (in one click)
which user created the page, rather than its appearance.

stuart wrote:

Why not just make REVISIONID take a parameter, so {{REVISIONID:1}} gives the first revision ID, {{REVISIONID:2}} gives the second, {{REVISIONID:0}} gives the current revision ID just like {{REVISIONID}}, {{REVISIONID:-1}} gives the previous revision ID, {{REVISIONID:-2}} gives the ID of the revision before the previous revision, and so forth?

FYI, bug 23960 was filed requesting the implementation of comment #9's proposal.

Bryan.TongMinh wrote:

The performance penalty for this feature is too big for this feature to be implemented, I believe.

(In reply to comment #6)

(In reply to comment #4)

it is quite useful if you need a unique number for a page
which does not change in the course of editing. To use the name of a page is
not useful since this is variable. It would serve as a very good reference and
makes querying easier.

{{PAGEID}} would serve that purpose just fine, but I don't believe it exists.

Hmm, I don't remember why I didn't comment here, but for that purpose, it would be enough to just implement a wrapper for the same variable that is returned in $wgArticleId (check any mw page source). I think I talked to someone in MediaWiki-General about this, and I don't recall having been told that'd be hard to do.

(In reply to comment #12)

Hmm, I don't remember why I didn't comment here, but for that purpose, it would
be enough to just implement a wrapper for the same variable that is returned in
$wgArticleId (check any mw page source). I think I talked to someone in
MediaWiki-General about this, and I don't recall having been told that'd be hard to
do.

A magic word for the page ID would be easy. Comment #11 is right that retrieving the first revision ID is an expensive operation.

The purpose of this bug was to get an ID which is not changeable as editing for a certain page progresses over time. Actually I did not know that there is a page ID (wgArticleId) available too. I thought that there are only revisions (wgCurRevisionId) available on MediaWiki, which was admittedly pretty stupid of me. {{PAGEID}} would serve this purpose and to have it would be very cool.

For the record, both the "page id" and "first revision id" are variable and able to change without there being an edit made as far as I know. At the least they're not unique or guaranteerd to stay forever the same (the first revision could be deleted or hidden, then what ?).

Or perhaps it was already deleted (to the archive table that is, not rev_del/hidden'ed), once it's restored, stuff changes first revision is no longer the first revision. Not to forget Special:Import, entirely new revisions coulid be inserted into the middle or before the history. is "first" revision referring to the first created, oldest timestamp or lowest revision number ?

Or article histories are merged, then the the page id could change. Or when the entire page is deleted and undeleted (not sure if the id always stays the same when (un)deleting, I think sometimes or always a new page-id is assigned)

Although there certainly are some magic words that are able to change without editing the page, given that pageid/first-revision-id are (also) able to change, the possible usecases may not apply anymore.

Anyway, just my 2c,

Krinkle

the article id seems unlikely to change given that it is the page_id in the page table), except during deletion/undeletion, which arguably is like creating a new page. At the very least it stays constant through edits which is what is requested.

As an aside, an additional usecase for a {{PAGEID}} magic word, would be able to make short urls for a page using the curid url parameter (this would be useful on share this type templates, and is actually done on wikinews in js).

Here's what I've drawn

• the article id (aka the page_id in the page table) fulfills all the usecases requested in this bug, perhaps even better then firstrevisionid
• FirstRevisionId is very unlikely to happen due to it being expensive to determine.

Thus I'm changing the summary to be asking for {{ARTICLEID}} magic word

Created attachment 8872
patch adding {{PAGEID}} variable and {{ARTICLEID}} as an alias

attachment pageid.patch ignored as obsolete

So before we go and introduce this. Can we please get back or describe a usecase for this ?

The original request wanted to the author username and/or permalink to the first revision, that's not what introducing {{PAGEID}} will do.

At some later point there were references to *JavaScript* variables named wgArticleId which already work in MediaWiki and have been for sometime, so we won't need {{PAGEID}} in *wikitext* for that.

I'm in general a bit leery on introducing magic words, especially ones that work on top of technical implementation details which are usually not interesting to the user.

So base question (keeping in mind that I'm not against this variable, just want to make sure we do it for a good reason): Why do we need {{PAGEID}} as a magic word in core and what should it enable to do (usecases).

Thanks,
– Krinkle

Created attachment 8873
patch introducing {{pageid}} variable

remove {{articleid}} alias, per suggestion by Krinkle on IRC (user-visible instances of "article" are being replaced with "page")

Attached:

(In reply to comment #18)

So before we go and introduce this. Can we please get back or describe a
usecase for this ?

The original request wanted to the author username and/or permalink to the
first revision, that's not what introducing {{PAGEID}} will do.

No, that was just miscommunication. The author did clarify his original intentions later on: "The purpose of this bug was to get an ID which is not changeable as editing for a certain page progresses over time. (...) {{PAGEID}} would serve this purpose and to have it would be very cool."

At some later point there were references to *JavaScript* variables named
wgArticleId which already work in MediaWiki and have been for sometime, so we
won't need {{PAGEID}} in *wikitext* for that.

We do if we want to use it in templates, as Bawolff suggested.

I'm in general a bit leery on introducing magic words, especially ones that
work on top of technical implementation details which are usually not
interesting to the user.

I think Bawolff's short link proposal would be of interest. Granted, curid links aren't supposed to be a 100% stable permalinks, but the uses for a short url are mostly ephemeral / informal. For example, to share a Signpost article on Twitter, etc. It's not a big deal if the link eventually rots, especially since that's very unlikely (tough not impossible) to happen. In any case, we do rot links daily when deleting articles, so I don't think this should be an impediment.

Those links are likely generated by JavaScript, right ? That has access to these variables already.
If it's not done by JavaScript, then it should probably be an extension implementing something like <sociallinks /> which would output shortlinks and stuff for social networks. Agian, not wikitext so has access to these variables already.

gangleri wrote:

Hi! I was not here for years. Thanks for being notified via MediaWiki-General IRC about this discussion.
simple issues first: looking at the source code of any MW page you will see:
"''mediaWiki.config.set({"wgCanonicalNamespace": ... "wgArticleId": number ...''". So the numbers are accesible for everybody.

A script is available at
http://wikimania2011.wikimedia.org/w/index.php?curid=2866
where the variable is used; see also [[Bugzilla:021572]].

When posting the request I was searching for something more simple as
special:curid/value or /special:ArticleId/value (all being case insensitive).

Three weeks ago I noticed more handicaps compared with REDIRECT pages on new FireFox: FireFox will ask for a click for link change confirmation.

The most critical examples relating to the Personendaten / Personendatendatei are available at:
http://de.wikipedia.org/wiki/Vorlage_Diskussion:Normdaten#Sonderf.C3.A4lle
http://de.wikipedia.org/w/index.php?curid=198436&redirect=no witch are related to the toolserver and semantic web applications.
(It is necessary to place templates in a redirect page but they can not be made visible - this is another request. I have seen it only twice.)

I joined a group of Esperanto librarians staring to build a common worldwide database. In a first step they will need to identify authors by name. Due to historical reasons numerous variants might be used. This might fit on a reacent started work in internationalizating and porting [[Authority control]]. Some 90+ examples are available at [[eo:/Kategorio:Ligoj_al_bibliotekoj]].

Many parameters displayed at the bottom of each page are / might be relevant in some years from now. People will nead stable references. To avoid deleting / undeleting identiifcation problems one would / could / might handle a stack of ArticleId numbers.

To present in a few words the toolserver person data colllection see
http://de.wikipedia.org/w/index.php?curid=3578818 (wgArticleId) Jimmy Wales

The page can be referenced in three methods:
http://toolserver.org/~apper/pd/person/viaf/96800423
http://toolserver.org/~apper/pd/person/peende/3578818 (wgArticleId)
http://toolserver.org/~apper/pd/person/Jimmy_Wales

Probablly wgArticleId was not communicated to other sites. Please identify the
WorldCat link at the bottom of [[Anne Frank]]
http://www.worldcat.org/identities/lccn-n79-125789 Frank, Anne 1929-1945
the coding is:
http://en.wikipedia.org/wiki/Special:Search?search=Anne_Frank

Coclusion I would be very happy about the availability of that magic word, however it will be called. Greentings from Munich.

gangleri wrote:

wow! I am neither skilled in JavaScript nor in css. See anyway:
http://wikimania2011.wikimedia.org/w/index.php?oldid=16551
This is a shortedned url ;-)

gangleri wrote:

Sorry for the third post! This is a workaround if you want to copy "wgArticleId" manually and if you add it manually into the page. This is not what is requited but avoids looking at the page source code / at the generated link. Compared to the painful method used before it saves 90% of time. Copy and paste still might cause negligence ( www.dict.cc/german-english/Unachtsamkeit.html ) errors.

(In reply to comment #21)

Those links are likely generated by JavaScript, right ? That has access to
these variables already.
If it's not done by JavaScript, then it should probably be an extension
implementing something like <sociallinks /> which would output shortlinks and
stuff for social networks. Agian, not wikitext so has access to these variables
already.

On Wikinews we have a wiki template, that uses javascript as a _really ugly_ hack to re-write url's to use the page_id (see [[n:template:Social Bookmarks]]). Ideally that template would just be plain wiki-markup. I don't really see how this is any more a technical implementation detail than say {{REVISIONID}} is. I also think social bookmark links are the ideal case for a template - Its just a link to some other websites, and presumably with time the user would want to change which websites as different one's gain in popularity. There is really not anything that weird about these links requiring an extension (imho)

(Obviously the use-cases here aren't exactly earth-shattering, but they do exist, and the negative consequences of yet another semi-useless magic word are minimal in my opinion)

sumanah wrote:

+need-review so Waldir's patch gets reviewed. Thanks for the patch, Waldir.

Added in r107006.

I have reverted r107006 (see r108002) since the patch does not seem to work on preview.

(In reply to comment #28)

I have reverted r107006 (see r108002) since the patch does not seem to work on
preview.

Works fine in preview for me. The one exception being it wont work when previewing a newly created page (or more specifically it will say page id 0, because pages that don't exist don't have an id yet).

I personally think that behaviour is fine (After all {{REVISONID}} and friends don't work on preview either). The only thing that I think needs changing is to mark the page as vary-revision if the page id is 0 (since it will vary on save)

gangleri wrote:

(In reply to comment #22)

To present in a few words the toolserver person data colllection see
http://de.wikipedia.org/w/index.php?curid=3578818 (wgArticleId) Jimmy Wales

I noticed some days ago that w/index.php can be omited. The shorter url
http://de.wikipedia.org/?curid=3578818 (wgArticleId) Jimmy Wales

can be used also.

I was absent for a long time. Please follow also the discussion at http://www.mediawiki.org/?curid=84252 i.e. [[mw:Thread:Project:Support desk/Is http://de.wikipedia.org/?curid=2809853 an exploit or can this be considered as a legitimate stable redirect ?]]
Thanks for any comments there. Reinhardt

Waldir and Hashar did some pair programming at the Berlin hackaton.

Change proposal is in Gerrit at:

https://gerrit.wikimedia.org/r/9858

Change was merged in, thanks Waldir.

I did add a doc on Mediawiki Help:Magic_words article, but that will not be functional till we deploy that change on the live site :/

http://www.mediawiki.org/w/index.php?title=Help:Magic_words&diff=553229&oldid=545584

I did some tweaks to your doc edit. Thanks for the help with fixing and submitting the patch!

This also solved part of bug 21572.