Quick feature suggestion - a {{CURRENTUSER}} magic word similar to {{PAGENAME}} magic words, which returns the username of the currently logged in user, or else the IP of the un-logged in user. This would be very useful for general per-user customisation of the site, delivering user-centric information, etc., through templates.
Virgil,
Already logged and closed as WONTFIX. http://bugzilla.wikimedia.org/show_bug.cgi?id=4196
NB: I COMPLETELY agree with you that this would be incredibly handy.
On 13/11/2007, Jamie Hari jamie@marveldatabase.com wrote:
Already logged and closed as WONTFIX. http://bugzilla.wikimedia.org/show_bug.cgi?id=4196 NB: I COMPLETELY agree with you that this would be incredibly handy.
Hmm, I understand Uncyclopedia already has this implemented and working.
- d.
Someone please correct me if I am wrong, but I think they used a javascript for this... Not an ideal implementation, especially since javascript won't work for every user.
Anyone else see value in such a MAGICWORD implementation?
Jamie
On 11/13/07, David Gerard dgerard@gmail.com wrote:
On 13/11/2007, Jamie Hari jamie@marveldatabase.com wrote:
Already logged and closed as WONTFIX. http://bugzilla.wikimedia.org/show_bug.cgi?id=4196 NB: I COMPLETELY agree with you that this would be incredibly handy.
Hmm, I understand Uncyclopedia already has this implemented and working.
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
--- Jamie Hari jamie@marveldatabase.com wrote:
Someone please correct me if I am wrong, but I think they used a javascript for this... Not an ideal implementation, especially since javascript won't work for every user.
Anyone else see value in such a MAGICWORD implementation?
Jamie
For the last time, it's not that nobody sees value in it, it's that it simply cannot be implemented without almost completely losing the performance benefits due to caching. Unless you're happy to look at error pages 99% of the time, this is no good.
-Gurch
-Gurch
For the last time, it's not that nobody sees value in it, it's that it simply cannot be implemented without almost completely losing the performance benefits due to caching. Unless you're happy to look at error pages 99% of the time, this is no good.
I guess there are basically three places it can be done:
* as an actual magic word, negating the cache * in javascript, which doesn't work for everyone * as a list-minute server-side thing, which would work but parser functions etc wouldn't work on it.
steve
On Nov 13, 2007 11:43 AM, Matthew Britton matthew.britton@btinternet.com wrote:
--- Jamie Hari jamie@marveldatabase.com wrote:
Someone please correct me if I am wrong, but I think they used a javascript for this... Not an ideal implementation, especially since javascript won't work for every user.
Anyone else see value in such a MAGICWORD implementation?
Jamie
For the last time, it's not that nobody sees value in it, it's that it simply cannot be implemented without almost completely losing the performance benefits due to caching.
That's complete nonsense, though. There are numerous ways to implement this without having any impact whatsoever on performance. Maybe the most straightforward solution would impact performance, but that doesn't mean "it simply cannot be implemented".
Think about it for half a millisecond. You already put the username at the top of the page (next to "my talk"). How is that done? Either you've figured out how to cache part of the content while keeping another part dynamic, or you don't cache logged in users anyway.
Anthony schreef:
Either you've figured out how to cache part of the content while keeping another part dynamic
We have. It's called the parser cache.
or you don't cache logged in users anyway.
Since user preferences (show/hide TOC, section numbers, date format, etc.) vary, the first view of a page is probably not cached. Any subsequent view would be cached, until the page (or a template it transcludes) is edited. That's no problem for {{USERNAME}}, though.
Roan Kattouw (Catrope)
I see a very simple solution to all this cacheing. Store the uninterpreted magic word in the cache, and replacing it with the user's name on ultimate page-display with a very quick pass.
This means that the magic word can't be used in any kind of {{#ifeq:}} formulation, or suchlike, but it CAN be used in any transclusionary way e.g. "Hello John Doe, welcome to Wikipedia", or "You are logged in as John Doe" or "Go to [[User:John Doe]] to see your userpage" or "Go to [[Main Page/John Doe]] for your personalised homepage", etc. i.e. In any place where the usage of {{USERNAME}} actually outputs the username it will work (the raw code "{{USERNAME}}" will simply be thrown about through templates and outputted, then swapped at load time).
This means that any usage such as {{#ifeq:{{USERNAME}}|John Doe|Hey man}} will interpret "{{USERNAME}}" as a literal string, but any usage such as {{template|data|{{USERNAME}}}}, which simply moves the parameter to a point inside an infobox, or something, will (although strictly still treating the string literally), ultimately be replaced with the current username on load time.
On 13/11/2007, Roan Kattouw roan.kattouw@home.nl wrote:
Anthony schreef:
Either you've figured out how to cache part of the content while keeping another part dynamic
We have. It's called the parser cache.
or you don't cache logged in users anyway.
Since user preferences (show/hide TOC, section numbers, date format, etc.) vary, the first view of a page is probably not cached. Any subsequent view would be cached, until the page (or a template it transcludes) is edited. That's no problem for {{USERNAME}}, though.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jamie Hari wrote:
Someone please correct me if I am wrong, but I think they used a javascript for this... Not an ideal implementation, especially since javascript won't work for every user.
Anyone else see value in such a MAGICWORD implementation?
Jamie
You can find an implementation in the list archives (either this or mediawiki-l).
Stephen Bain wrote:
Matthew Britton wrote:
Once rendered, each page is cached and not re-rendered until it is edited, a template it transcludes changes, or it is purged. This feature would require the page to be re-rendered for each unique user that viewed it.
Doesn't this happen anyway? A logged-in user viewing a page for the first time will never get a cached version.
No. The *rendered article* is cached, and shared between all the users (which can't be done if a piece of it changes between users), as opposed to the bar where you see your name. You can disable caching on your preferences, though.
No. The *rendered article* is cached, and shared between all the users (which can't be done if a piece of it changes between users), as opposed to the bar where you see your name. You can disable caching on your preferences, though.
I think a few versions are cached, depending on prefs (date formats, stub links, etc). Each version is only shared between those with the same prefs. Of course, this results in far fewer versions that giving each user a different version. (I stress the "I think", I've never fully understood the intricacies of MediaWiki's caching.)
--- David Gerard dgerard@gmail.com wrote:
On 13/11/2007, Jamie Hari jamie@marveldatabase.com wrote:
Already logged and closed as WONTFIX. http://bugzilla.wikimedia.org/show_bug.cgi?id=4196 NB: I COMPLETELY agree with you that this would be
incredibly handy.
Hmm, I understand Uncyclopedia already has this implemented and working.
- d.
Yes, and Uncyclopedia gets an insignificantly small fraction of the traffic Wikimedia gets.
Once rendered, each page is cached and not re-rendered until it is edited, a template it transcludes changes, or it is purged. This feature would require the page to be re-rendered for each unique user that viewed it.
If you just want this on your personal wiki, just use Uncyclopedia's implementation.
If you want it on Wikimedia wikis, either rewrite MediaWiki from scratch so it can somehow handle re-rendering the page every time it is viewed without any performance hit, or donate eleventy billion dollars' worth of hardware to the Foundation.
-Gurch
On Nov 14, 2007 3:39 AM, Matthew Britton matthew.britton@btinternet.com wrote:
Once rendered, each page is cached and not re-rendered until it is edited, a template it transcludes changes, or it is purged. This feature would require the page to be re-rendered for each unique user that viewed it.
Doesn't this happen anyway? A logged-in user viewing a page for the first time will never get a cached version.
On 11/13/07, Stephen Bain stephen.bain@gmail.com wrote:
Doesn't this happen anyway? A logged-in user viewing a page for the first time will never get a cached version.
Sure they will, if someone with the same parse-affecting preferences has viewed it before them. And they don't have the "no cached pages" preference on.
On 11/13/07, Anthony wikimail@inbox.org wrote:
That's complete nonsense, though. There are numerous ways to implement this without having any impact whatsoever on performance. Maybe the most straightforward solution would impact performance, but that doesn't mean "it simply cannot be implemented".
No, but what is true is that there is no way to have a magic word that consistently reflects the current user name, and can be used in various logical constructs, without invalidating the parser cache on each view (for re-views not by the same user). Invalidating the parser cache on each view for a moderately-trafficked page would be, presumably, a large hit to performance, thus the claim.
Presumably. What's the hit ratio for the parser cache for logged-in users anyway?
Think about it for half a millisecond. You already put the username at the top of the page (next to "my talk"). How is that done? Either you've figured out how to cache part of the content while keeping another part dynamic, or you don't cache logged in users anyway.
Most of the use of this suggestion is prevented if the magic word cannot be used as, e.g., a template parameter. To use it as, e.g., a template parameter, the page must be re-parsed on every page view. A parse takes a little under a second for an average page, nowadays. That's a lot of CPU time when you add it all up. Just inserting the username in *after* you've already parsed everything would be no big performance hit, necessarily, just as the username at the upper right isn't -- but as I say, it wouldn't do everything that the requesters really wanted. It also wouldn't be consistent with the behavior of other magic words, which is confusing.
Now, if you wanted to have such a variable so that you could *subst* it, that's a reasonable request. It would then have the same uses as {{CURRENTTIME}}, i.e., not perfectly accurate but useful for some things anyway. I suggested that on the bug, as I recall.
On Nov 13, 2007 6:41 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On 11/13/07, Stephen Bain stephen.bain@gmail.com wrote:
Doesn't this happen anyway? A logged-in user viewing a page for the first time will never get a cached version.
Sure they will, if someone with the same parse-affecting preferences has viewed it before them. And they don't have the "no cached pages" preference on.
I'm confused; what exactly is in the cache for logged in users?
The HTML I see coming out the end has encoded username variable and username in scripts and so forth.
I always assumed that logged in users generated a new HTML render every time they hit a page, and that we assumed that logged in users were a small enough fraction of total page views that it wasn't a big deal. But I'm not familiar with the Wikipedia cacheing at all in detail; I've run a lot of Mediawiki servers but never bothered to cache anything (none of them had enough hits to make it worthwhile trying).
So... what's the underlying mechanism?
Thanks...
On 11/13/07, George Herbert george.herbert@gmail.com wrote:
I'm confused; what exactly is in the cache for logged in users?
The cache under discussion is the parser cache. This stores the HTML for a given wikitext string. There are other caches as well, like the Squid cache and the sidebar cache and so on.
But I'm not familiar with the Wikipedia cacheing at all in detail; I've run a lot of Mediawiki servers but never bothered to cache anything (none of them had enough hits to make it worthwhile trying).
The parser cache is on by default, I'm fairly sure.
George Herbert wrote:
I'm confused; what exactly is in the cache for logged in users?
The HTML I see coming out the end has encoded username variable and username in scripts and so forth.
I always assumed that logged in users generated a new HTML render every time they hit a page, and that we assumed that logged in users were a small enough fraction of total page views that it wasn't a big deal. But I'm not familiar with the Wikipedia cacheing at all in detail; I've run a lot of Mediawiki servers but never bothered to cache anything (none of them had enough hits to make it worthwhile trying).
So... what's the underlying mechanism?
Thanks...
There's a lot of caches. That's how wikipedia survives having so much visitors ;)
When you make a petition to wikimedia wikis, it will go to a squid cluster: pmtpa, knams or yaseo. A cache fail at knams or yaseo passes the petition to pmtpa squids. A cache fail at pmtpa passes the petition to the apaches.
The squids will only serve the page if they have served the same url for the same user before, where the same user means: -You, if you're logged in (time since last time your cookie changed). -Another anonymous user, if you're not logged in. Note how mediawiki has a flag at LocalSettings, to show your ip on the top as it does with logged users. By disabling it, all anonymous get the same html and it can be cached on the squids. When a page is modified, the squids are told not to remember that page any more.
When the petition arrives to the apaches, it will be served, php drops in, and assembles a bunch of stuff, in which adding your username is no problem. It uses: -Your username, permissions, preferences... which are stored in your session. -The skin at a php file. -The content of Mediawiki: messages, which have its own cache. -The article content is cached. -The diffs are cached too.
If you keep those groups untouched, there's no problem adding more dynamic things. If some of them is not in the cache (stored at memcached), it will need to be generated, for which you'll need to ask the db. Of all of them, parsing is the most expensive and breaking its caching will send you to the hell of getting "Wikipedia has a problem" errors on each edit.
Have i missed something?
Right... So nothing is cached in squid between logged-in users, each of those gets a new parse and render of a page they go to in each session. If I hit http://en.wikipedia.org/wiki/FooBar twice in one session and it hasn't been updated, I get the Squid cache of it, but otherwise nothing. And if User:FredJoeBob hits it, it generates a new render of the page, which is cached for him but not for me.
However, the parsed article is cached until someone changes something in the underlying article. And that's shared.
So the specific concern is that putting some additional level of parsing between the memcached article text and the final output HTML will slow things down? And that's where it would have to go for the {{USERNAME}} to expand out properly.
I am not a Javascript guy, so I apologize in advance if this is a dumb question, but... Is it possible to make {{USERNAME}} some javascript which expands it on the client side, so the server just provides that JS to the browser and lets you figure it out? That would be the same JS code for everyone, so the underlying parsed article would stay in memcached unchanged...
I don't know if JS can carry the equivalent of a global variable within the page, so I'm not sure if you could set such in the already per-user generated header stuff and then expand it with JS in the fixed page content part. I guess that's what I'm thinking of here. But I freely admit that I don't know if that's possible or not.
-george william herbert
On Nov 14, 2007 1:35 PM, Platonides Platonides@gmail.com wrote:
George Herbert wrote:
I'm confused; what exactly is in the cache for logged in users?
The HTML I see coming out the end has encoded username variable and
username
in scripts and so forth.
I always assumed that logged in users generated a new HTML render every
time
they hit a page, and that we assumed that logged in users were a small enough fraction of total page views that it wasn't a big deal. But I'm
not
familiar with the Wikipedia cacheing at all in detail; I've run a lot of Mediawiki servers but never bothered to cache anything (none of them had enough hits to make it worthwhile trying).
So... what's the underlying mechanism?
Thanks...
There's a lot of caches. That's how wikipedia survives having so much visitors ;)
When you make a petition to wikimedia wikis, it will go to a squid cluster: pmtpa, knams or yaseo. A cache fail at knams or yaseo passes the petition to pmtpa squids. A cache fail at pmtpa passes the petition to the apaches.
The squids will only serve the page if they have served the same url for the same user before, where the same user means: -You, if you're logged in (time since last time your cookie changed). -Another anonymous user, if you're not logged in. Note how mediawiki has a flag at LocalSettings, to show your ip on the top as it does with logged users. By disabling it, all anonymous get the same html and it can be cached on the squids. When a page is modified, the squids are told not to remember that page any more.
When the petition arrives to the apaches, it will be served, php drops in, and assembles a bunch of stuff, in which adding your username is no problem. It uses: -Your username, permissions, preferences... which are stored in your session. -The skin at a php file. -The content of Mediawiki: messages, which have its own cache. -The article content is cached. -The diffs are cached too.
If you keep those groups untouched, there's no problem adding more dynamic things. If some of them is not in the cache (stored at memcached), it will need to be generated, for which you'll need to ask the db. Of all of them, parsing is the most expensive and breaking its caching will send you to the hell of getting "Wikipedia has a problem" errors on each edit.
Have i missed something?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
"George Herbert" george.herbert@gmail.com wrote in message news:38a7bf7c0711141448x63fce7d8hf6798d840a49c0be@mail.gmail.com...
I am not a Javascript guy, so I apologize in advance if this is a dumb question, but... Is it possible to make {{USERNAME}} some javascript
which
expands it on the client side, so the server just provides that JS to the browser and lets you figure it out? That would be the same JS code for everyone, so the underlying parsed article would stay in memcached unchanged...
I don't know if JS can carry the equivalent of a global variable within
the
page, so I'm not sure if you could set such in the already per-user generated header stuff and then expand it with JS in the fixed page
content
part. I guess that's what I'm thinking of here. But I freely admit that
I
don't know if that's possible or not.
There is no need for javascript. It would be trivial for the main parser to ignore a {{CURRENTUSER}} magic word, and then for this to be replaced when the HTML page is compiled from it's various sources (using 'anonymous user' or something if it was an anon).
This has already been proposed in this thread somewhere as a solution that wouldn't break caching. However, it means that constructs that depend on the value when the wikitext is being parsed (e.g. parser functions, such as {{#ifeq:}}) won't work as expected, because {{CURRENTUSER}} is exapanded at the end, not the beginning, of the parse.
- Mark Clements (HappyDog)
But I don't think that's a problem at all - the main functionality of this word would be achieved. It could be added as a parser extension (i.e. not actually written into MediaWiki) that we can install on the projects for all the useful uses it can be used for?
On 15/11/2007, Mark Clements gmane@kennel17.co.uk wrote:
"George Herbert" george.herbert@gmail.com wrote in message news:38a7bf7c0711141448x63fce7d8hf6798d840a49c0be@mail.gmail.com...
I am not a Javascript guy, so I apologize in advance if this is a dumb question, but... Is it possible to make {{USERNAME}} some javascript
which
expands it on the client side, so the server just provides that JS to
the
browser and lets you figure it out? That would be the same JS code for everyone, so the underlying parsed article would stay in memcached unchanged...
I don't know if JS can carry the equivalent of a global variable within
the
page, so I'm not sure if you could set such in the already per-user generated header stuff and then expand it with JS in the fixed page
content
part. I guess that's what I'm thinking of here. But I freely admit
that I
don't know if that's possible or not.
There is no need for javascript. It would be trivial for the main parser to ignore a {{CURRENTUSER}} magic word, and then for this to be replaced when the HTML page is compiled from it's various sources (using 'anonymous user' or something if it was an anon).
This has already been proposed in this thread somewhere as a solution that wouldn't break caching. However, it means that constructs that depend on the value when the wikitext is being parsed (e.g. parser functions, such as {{#ifeq:}}) won't work as expected, because {{CURRENTUSER}} is exapanded at the end, not the beginning, of the parse.
- Mark Clements (HappyDog)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Herbert, Mark, Virgil, everyone: Yes, it can be done with javascript. Yes, iit could be ignored. But then it wouldn't be a magic word. It'd be yet another breaking parser case. *It can be already done with JavaScript*. Just put a<span or <div with identifying id or class and change its content at monobook.js
On 14/11/2007, Simetrical Simetrical+wikilist@gmail.com wrote:
Most of the use of this suggestion is prevented if the magic word cannot be used as, e.g., a template parameter. To use it as, e.g., a template parameter, the page must be re-parsed on every page view. A parse takes a little under a second for an average page, nowadays. That's a lot of CPU time when you add it all up.
Owwwwwwwwww.
That's a damn good reason to rewrite the parser in "sane."
- d.
On 11/13/07, Anthony wikimail@inbox.org wrote:
That's complete nonsense, though. There are numerous ways to implement this without having any impact whatsoever on performance. Maybe the most straightforward solution would impact performance, but that doesn't mean "it simply cannot be implemented".
No, but what is true is that there is no way to have a magic word that consistently reflects the current user name, and can be used in various logical constructs, without invalidating the parser cache on each view (for re-views not by the same user). Invalidating the parser cache on each view for a moderately-trafficked page would be, presumably, a large hit to performance, thus the claim.
Allowing it to be used in logical constructs without a big performance hit would be difficult, as it'd require rewriting the parser cache (and preferably the parser itself), though still not impossible. In any case, if the intent is to allow logical constructs I can see why it'd be closed as wontfix. At least wontfix until code is provided or the foundation hires an actual staff.
Just inserting the username in *after* you've already parsed everything would be no big performance hit, necessarily, just as the username at the upper right isn't -- but as I say, it wouldn't do everything that the requesters really wanted.
The request in this thread, by Virgil Ierubino, didn't seem to require anything more than a last nanosecond substitution.
What if everything gets parsed and cached except the logical constructs? Or even better everything except the logical constructs which can't be immediately reconciled?
It also wouldn't be consistent with the behavior of other magic words, which is confusing.
A valid point, but simply renaming it <<CURRENTUSER>> or something could solve that.
On 11/14/07, Anthony wikimail@inbox.org wrote:
... I can see why it'd be closed as wontfix. At least wontfix until code is provided or the foundation hires an actual staff.
Ouch... um... they do have an actual staff.
The request in this thread, by Virgil Ierubino, didn't seem to require
anything more than a last nanosecond substitution.
http://bugzilla.wikimedia.org/show_bug.cgi?id=10336
It also wouldn't be consistent with the behavior of
other magic words, which is confusing.
A valid point, but simply renaming it <<CURRENTUSER>> or something could solve that.
If you want to subst: a user name, it should be consistent with "~~~" and "~~~~", etc. We probably shouldn't start a NEW set of 'MYSTICWORDS' with <<>> notation....
On Nov 14, 2007 10:14 AM, Jamie Hari jamie@marveldatabase.com wrote:
On 11/14/07, Anthony wikimail@inbox.org wrote:
... I can see why it'd be closed as wontfix. At least wontfix until code is provided or the foundation hires an actual staff.
Ouch... um... they do have an actual staff.
For software development? All I see is a CTO and an IT manager. I suppose you could say Brion is the staff.
Oh yeah, there's a software development contractor and a networking coordinator too. So I guess you could say Brion and/or Tim are the staff (looks to me like Tim is the entire software development staff and Brion is CTO/manager). Obviously not enough to rewrite the parser, in any case.
It also wouldn't be consistent with the behavior of
other magic words, which is confusing.
A valid point, but simply renaming it <<CURRENTUSER>> or something could solve that.
If you want to subst: a user name, it should be consistent with "~~~" and "~~~~", etc.
I'm not suggesting a subst:. The username would reflect the person reading the page, not the person who made the edit. It's nothing like the tilde signatures.
We probably shouldn't start a NEW set of 'MYSTICWORDS' with <<>> notation....
I don't see why not. If it has a different functionality, it should have a different notation.
wikitech-l@lists.wikimedia.org