Petr Kadlec wrote:
> Hi, folks.
>
> Recently, the problem of user tracking via third party companies has
> been debated on mailing lists. I wonder, if an inclusion of the jQuery
> library linked directly from Google servers (!) does not qualify as a
> bad idea, too… (Even though no user tracking h
Aryeh Gregor wrote:
> On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouw 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
> 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 c
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 cha
2009/6/26 Robert Rohde :
> 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. If install
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 a
On Fri, Jun 26, 2009 at 5:24 PM, Michael Dale wrote:
> The difference in the context of the script-loader is we would read the
> version from the mediaWiki js pages that are being included and the
> $wgStyleVersion var. (avoiding the need to shift reload) ... in the
> context of rendering a normal
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
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 media
On Fri, Jun 26, 2009 at 4:49 PM, Gregory Maxwell wrote:
> Hm. Unique ids?
>
> Does this mean the every page on the site must be purged from the
> caches to cause all requests to see a new version number?
>
> Is there also some pending squid patch to let it jam in a new ID
> number on the fly for ev
On Fri, Jun 26, 2009 at 4:33 PM, Michael Dale 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 cached forever w
We should have a copy of jquery in mediaWiki ~soon~ ... although its a
good point that it would be nice to centrally locate all our static
mediWiki files for improved cache-ability across sites. If we could tie
the version number to the request then we can just set it to never expire.
--michael
On Fri, Jun 26, 2009 at 12:01 PM, Gerard
Meijssen 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
http://en.wikipedia.org/wiki/Ten_Commandme
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
You're patching already-existing functionality at the File level, so it
should be ok to just plop it in there. I'm not sure how this will affect
the ForeignApi interface, so it'd be worth testing there too.
From what I can tell at a (very) quick glance, it shouldn't adversely
affect anything from
Which of all those file to change to apply my patch only to files in default
repository? Currently my patch is applied to File.php
http://bug-attachment.wikimedia.org/attachment.cgi?id=5833
If you just point me into right direction, I'll update the patch and upload
it myself.
Thank you,
The structure is LocalRepo extends FSRepo extends
FileRepo. ForeignApiRepo extends FileRepo directly, and
ForeignDbRepo extends LocalRepo.
-Chad
On Jun 26, 2009 3:15 PM, "Sergey Chernyshev"
wrote:
It's probably worth mentioning that this bug is still open:
https://bugzilla.wikimedia.org/show_bu
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 a
2009/6/26 Robert Rohde :
> 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 evaluating all
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ő
> Tim Starling wikimedia.org> writes:
>
> > {{subst:!}} no longer works as a separator between pa
On Fri, Jun 26, 2009 at 7:16 AM, Aryeh
Gregor wrote:
> On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouw 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 th
On Fri, Jun 26, 2009 at 11:46 AM, Andrew Garrett 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 tracking software.
On 26/06/2009, at 3:32 PM, Brian wrote:
> On Fri, Jun 26, 2009 at 2:44 AM, Stephen Bain
> wrote:
>
>> 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 i
On 26/06/2009, at 3:21 PM, Aryeh Gregor wrote:
> On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennett
> 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 le
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. If installed it automatically captures all con
>>
> I asked Domas whether it was and he said no; Tim, can you chip in on
> this?
where did I say no, and what was my 'no' about?
-- domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitec
On Fri, Jun 26, 2009 at 2:44 AM, Stephen Bain wrote:
> 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
> On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouw 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 arguments, an
2009/6/26 Chad :
> 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 array handling function
2009/6/26 Aryeh Gregor :
> 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 is some users would get old
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennett 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.
_
On Thu, Jun 25, 2009 at 11:33 PM, Tim Starling 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 not the most innocu
On Fri, Jun 26, 2009 at 9:48 AM, Aryeh
Gregor wrote:
> On Fri, Jun 26, 2009 at 6:24 AM, Andrew Garrett 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?
>
> ___
> Wik
On Fri, Jun 26, 2009 at 6:33 AM, Thomas Dalton 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 we'd shut down views
On Fri, Jun 26, 2009 at 6:24 AM, Andrew Garrett 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
Wikitech-l@lists.wikimedia.org
https://lists.
On Fri, Jun 26, 2009 at 12:07 PM, Aryeh
Gregor 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
different kinds of syntax:
1) Arti
Hi, folks.
Recently, the problem of user tracking via third party companies has
been debated on mailing lists. I wonder, if an inclusion of the jQuery
library linked directly from Google servers (!) does not qualify as a
bad idea, too… (Even though no user tracking has obviously been
intended, and
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
> periodic
2009/6/26 Stephen Bain :
> 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 create accessibl
2009/6/26 Brion Vibber :
> 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 lead to site-
On 25/06/2009, at 4:07 PM, Brion Vibber wrote:
> Quick note to all -- PHP 5.3.0 final release is scheduled for June 30.
> Everybody don't be shy about testing out your code with the release
> candidates! :)
>
> -- brion vibber (brion @ wikimedia.org)
Hooray for closures!
Do we have plans to up
On Fri, Jun 26, 2009 at 2:07 PM, Brian wrote:
>
> As an example, yesterday I wrote some code that basically says, "check the
> doi and http template parameters and check to make sure they begin with
> http, and if not add it." In any reasonable sort of language that lends
> itself to a reasonable s
42 matches
Mail list logo
