On Thu, Jun 25, 2009 at 10:35 PM, Tim Starlingtstarl...@wikimedia.org wrote:
snip
The community of people who work on such templates is an extremely
small, self-selected subset of the community of editors. It is that
tiny segment of the community that can code in this accidental
programming
2009/6/26 Brion Vibber br...@wikimedia.org:
Tim Starling wrote:
It's quite a complex feature. If you have a server that deadlocks or
is otherwise extremely slow, then it will block rendering for all
other attempts, meaning that the article can not be viewed at all.
That scenario could even
2009/6/26 Stephen Bain stephen.b...@gmail.com:
In the good old days someone would have solved the same problem by
mentioning in the template's documentation that the parameter should
use full URLs. Both the template and instances of it would be
readable.
Template programmers are not going to
Roan Kattouw wrote:
To get back to {{cite}}: the template itself contains no more than
some logic to choose between {{Citation/core}} and {{Citation/patent}}
based on the presence/absence of certain parameters, and
{{Citation/core}} does the same thing to choose between books and
periodicals.
On Fri, Jun 26, 2009 at 12:07 PM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
From the editor's point of view. Not from the view of the HTML
source, which is what the original proposal was looking at.
I guess.
I'm starting to get the initial pangs of an idea that we should have
On Fri, Jun 26, 2009 at 6:24 AM, Andrew Garrettagarr...@wikimedia.org wrote:
Hooray for closures!
Do we have plans to update the cluster?
Does it matter if MediaWiki still has to work on PHP 5.0?
___
Wikitech-l mailing list
On Fri, Jun 26, 2009 at 6:33 AM, Thomas Daltonthomas.dal...@gmail.com wrote:
Of course, the fact that everyone's first port of call after hearing
such news is to check the Wikipedia page is a fantastic thing, so it
would be really unfortunate if we have to stop people doing that.
He didn't say
On Fri, Jun 26, 2009 at 9:48 AM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
On Fri, Jun 26, 2009 at 6:24 AM, Andrew Garrettagarr...@wikimedia.org wrote:
Hooray for closures!
Do we have plans to update the cluster?
Does it matter if MediaWiki still has to work on PHP 5.0?
On Thu, Jun 25, 2009 at 11:33 PM, Tim Starlingtstarl...@wikimedia.org wrote:
Those templates can be defeated by reducing the functionality of
padleft/padright, and I think that would be a better course of action
than enabling the string functions.
The set of string functions you describe are
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennettstevag...@gmail.com wrote:
3) A limited number of admin-controlled special templates can use an
even wider range of features, including raw HTML.
Admins are not going to be allowed to insert raw HTML. At least, not
ordinary admins.
2009/6/26 Aryeh Gregor simetrical+wikil...@gmail.com:
But this sounds like a good idea. If a process is already parsing the
page, why don't we just have other processes display an old cached
version of the page instead of waiting or trying to reparse
themselves? The worst that would happen
2009/6/26 Chad innocentkil...@gmail.com:
I could be completely off here, but I thought the lowest supported
release was 5.1.x. Or that there was talk (somewhere?) of making
that the case.
Officially, MediaWiki supports PHP 5.0.x, but using it is recommended
against because it has some buggy
On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouwroan.katt...@gmail.com wrote:
The reason I believe breaking up templates improves performance is
this: they're typically of the form
{{#if:{{{someparam|}}}|{{foo}}|{{bar . The preprocessor will see
that this is a parser function call with three
On Fri, Jun 26, 2009 at 2:44 AM, Stephen Bain stephen.b...@gmail.comwrote:
In the good old days someone would have solved the same problem by
mentioning in the template's documentation that the parameter should
use full URLs. Both the template and instances of it would be
readable.
Template
On 26/06/2009, at 3:21 PM, Aryeh Gregor wrote:
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennettstevag...@gmail.com
wrote:
3) A limited number of admin-controlled special templates can use an
even wider range of features, including raw HTML.
Admins are not going to be allowed to insert raw
On 26/06/2009, at 3:32 PM, Brian wrote:
On Fri, Jun 26, 2009 at 2:44 AM, Stephen Bain
stephen.b...@gmail.comwrote:
In the good old days someone would have solved the same problem by
mentioning in the template's documentation that the parameter should
use full URLs. Both the template and
On Fri, Jun 26, 2009 at 11:46 AM, Andrew Garrettagarr...@wikimedia.org wrote:
They already can, with Javascript, so there's no XSS issue.
That ability may be removed in the future, and restricted to a smaller
and more select group. Witness the problems we've been having with
admins including
On Fri, Jun 26, 2009 at 7:16 AM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouwroan.katt...@gmail.com wrote:
The reason I believe breaking up templates improves performance is
this: they're typically of the form
Hoi,
At some stage Wikipedia was this thing that everybody can edit... I can not
and will not edit this shit so what do you expect from the average Joe ??
Thanks,
Gerard
2009/6/25 Tisza Gergő gti...@gmail.com
Tim Starling tstarling at wikimedia.org writes:
{{subst:!}} no longer works
2009/6/26 Robert Rohde raro...@gmail.com:
My understanding has been that the PREprocessor expands all branches,
by looking up and substituting transcluded templates and similar
things, but that the actual processor only evaluates the branches that
it needs. That's a lot faster than actually
It's probably worth mentioning that this bug is still open:
https://bugzilla.wikimedia.org/show_bug.cgi?id=17577
This will save not only traffic on subsequent page views (in this case:
http://www.webpagetest.org/result/090218_132826127ab7f254499631e3e688b24b/1/details/cached/it's
about 50K), but
I would quickly add that the script-loader / new-upload branch also
supports minify along with associating unique id's grouping gziping.
So all your mediaWiki page includes are tied to their version numbers
and can be cached forever without 304 requests by the client or _shift_
reload to get
On Fri, Jun 26, 2009 at 12:01 PM, Gerard
Meijssengerard.meijs...@gmail.com wrote:
Hoi,
At some stage Wikipedia was this thing that everybody can edit... I can not
and will not edit this shit so what do you expect from the average Joe ??
I can not (effectively) contribute to
On Fri, Jun 26, 2009 at 4:33 PM, Michael Dalemd...@wikimedia.org wrote:
I would quickly add that the script-loader / new-upload branch also
supports minify along with associating unique id's grouping gziping.
So all your mediaWiki page includes are tied to their version numbers
and can be
correct me if I am wrong but thats how we presently update js and css..
we have $wgStyleVersion and when that gets updated we send out fresh
pages with html pointing to js with $wgStyleVersion append.
The difference in the context of the script-loader is we would read the
version from the
Hoi,
In the past the existence of templates in one wiki has been used as an
argument to not accept an extension. With extensions you have functionality
that is indeed intended to be external to ordinary users but you are talking
about functionality that can be tested. With templates you have stuff
Aryeh Gregor wrote:
Any given image is not included on every single page on the wiki.
Purging a few thousand pages from Squid on an image reupload (should
be rare for such a heavily-used image) is okay. Purging every single
page on the wiki is not.
yea .. we are just talking about adding
2009/6/26 Robert Rohde raro...@gmail.com:
I'm going to mention this here, because it might be of interest on the
Wikimedia cluster (or it might not).
Last night I deposited Extension:Minify which is essentially a
lightweight wrapper for the YUI CSS compressor and JSMin JavaScript
compressor.
It probably depend on how getTimestamp() is implemented for non-local repos.
Important thing is not to have it return new values too often and return
real version of the image.
If this is already the case, can someone apply this patch then - don't want
to be responsible for such an important
This is a very good idea, and sounds much better than having those
the major problem with all dirty caching is that we have more than one
caching layer, and of course, things abort.
the fact, that people should be shown dirty versions instead of proper
article leads to situation where in
30 matches
Mail list logo
