simetrical(a)svn.wikimedia.org wrote:
> Revision: 30877 Author: simetrical Date: 2008-02-12 20:11:58
> +0000 (Tue, 12 Feb 2008)
>
> Log Message: ----------- Remove inexplicable $nt->isContentPage()
> check for rendering link colors in makeLinkObj(). I don't know why
> there should be any difference, and there isn't for the other methods
> of rendering links.
"Stub"ness isn't meaningful for, say, user or talk pages. Being short
isn't a crime there.
-- brion vibber (brion @ wikimedia.org)
I've been wrestling with Squid for a large site I'm contracting at
right now. I was curious - what version of Squid is WMF running now,
and would it be ok if someone sent me the configs so I can see how you
have it set up right now?
Is cache peering in use? Are you running Squid 3.0, and COSS or AUFS?
Thanks for any relevant info...
I will feed back anything that seems useful from what I've learned here.
--
-george william herbert
george.herbert(a)gmail.com
Hi Folks,
>From the wikipedia' system diagram, seems that Squid play an important
role in the system architecture.
But how does Squid handle user customized page?
E.g. A page containing user logon name or IP ect. at the top of the page?
I think squid can't handle this, right (Unless you are using squid 3 ESI)?
Regards,
Howard
http://www.lighttpd.net/ claims that Wikipedia is using this web server. The
HTTP headers coming from Wikipedia server are not consistnet with this
claim, and show that WIkipedia uses Apache. I've also noticed that Tim
Starling has contributed to Apache (and not Lighhttpd) suggesting some bug
fixes which could help Wikimedia wikis run smoother. So here is the
question: Which web server is Wikimedia really using? And if it is not
Lighhttpd, would somebody mind if I try to tell Lighttpd guys remove that
false claim from their pages?
tlaqua(a)svn.wikimedia.org wrote:
> * Making unmergable user ID(s) configurable rather than assuming ID 1 (on recommendation from Simetrical)
> * Now allows defining unmergable users by ID or user_name
Hmm, I notice a couple issues here still.
First, there's no blanket prohibition on numeric usernames in MediaWiki
(though some blacklist extensions forbid it). The weak comparisons here
will match both ID numbers *and* names, which may be a little odd.
Second, setting the default at 1 is a bit arbitrary and imho not a great
idea.
It probably would be cleaner to set the default limit by group
membership or permission key, since there's not necessarily anything
unique or special about id 1, and have the explicit user blacklist be by
username only for easier management.
-- brion vibber (brion @ wikimedia.org)
btongminh(a)svn.wikimedia.org wrote:
> +When using a shared image repository, it is impossible to see within MediaWiki whether a file
> +is used on one of the slave wikis. On Wikimedia this is handled by the CheckUsage tool on the
> +toolserver, but it is merely a hack of function that should be built in.
Woohoo! :)
> +GlobalUsage creates a new table globalimagelinks, which is basically the same as imagelinks, but
> +points to the usage on foreign wikis. The field il_from has been replaced by gil_wiki, gil_page
> +and gil_pagename, which contain respectively the interwiki prefix, page id and page name
> +including namespace of the linking page. Since the foreign wiki may use different namespaces ,
> +the namespace name needs to be included in the link as well.
One problem here is that at Wikimedia, we currently don't have a
complete interwiki prefix map. That is to say, not every wiki can be
reached from all other wikis by a unique interwiki prefix, and the
defined local interwiki prefix is not unique in the system.
For cross-wiki data tables we currently use the database name, which can
be internally mapped with reference to the SiteConfiguration array, but
it's a bit dirty.
-- brion vibber (brion @ wikimedia.org)
Would anyone have objections to deprecating $wgLocaltimezone and
$wgLocalTZoffset, and instead just basing local time calculations on
PHP's own notion of the local time zone (which can be set in
LocalSettings.php with putenv("TZ=...") or, for PHP 5.1.0 and above,
date_default_timezone_set())? It seems to me that we're already relying
on PHP's own timezone handling so much that we might as well go the
whole hog, and fix a bunch of actual and potential bugs in the process.
(This occurred to me while I was fixing bug 12815 and stumbling into all
sorts of wacky time zone weirdness. I really don't see any cleaner way
of fixing the whole mess than getting rid of both of these redundant
config variables entirely. The documentation of $wgLocalTZoffset alone
is a WTF in itself, seeing as the meaning of its value apparently
changed from hours to minutes(!) somewhere around version 1.7.0.)
In particular, this should allow people running PHP 5.1.0+ in safe mode
to change the time zone from the server default (bug 2658).
--
Ilmari Karonen
On Feb 7, 2008 1:45 PM, <tlaqua(a)svn.wikimedia.org> wrote:
> * Disallowing deleting user_id 1 (WikiSysop/Admin/whatever)
MediaWiki doesn't have any concept of a root user, and it seems like a
bad idea to try to enforce such an idea in an extension. User 1 is
just the one who set up the wiki, who might or might not be any kind
of special authority. On the English Wikipedia, user #1 is
[[User:Damian Yerrick]], who's not even a sysop. That's probably due
to import issues, but for another example, user #1 on kshwiki
(Kölsch-language Wikipedia) is [[ksh:User:Deprifry]], who has two
edits made in 2006 and is also not even a sysop.
Of course Wikimedia is odd in a lot of ways, but as far as third
parties go, it's certain that quite a few wikis are set up by
contractors or other people who aren't necessarily going to
participate in the wiki at all. Or even if they're some important
person at first, they might eventually resign or be ousted. It's
weird and potentially annoying to add this restriction arbitrarily.
It protects someone who might not need protection, and doesn't protect
many other people whom you might want to protect.
If you're going to do any kind of restriction like this, IMO, make it
a config option, like $wgUnmergeableUsers. I guess you could
initialize it to array( 1 ), but I'd still leave it empty by default,
personally.
On Feb 8, 2008 12:20 PM, <huji(a)svn.wikimedia.org> wrote:
> +/**
> + * Lists (fixing for RTL display_
> + */
> +body.rtl #body-content ul { display:table; }
> +body.rtl #body-content ol { display:table; }
Could you expand on the reason for this a little? It seems pretty
odd. There seems to be no element with id="body-content" in any skin,
or at least not on a typical page view, and I don't understand why you
would want to try setting lists to display as tables. That should do
all sorts of weird (if perhaps subtle) things, per the standard.