Wikitech-l June 2003

wikitech-l@lists.wikimedia.org

54 participants
82 discussions

Admin questions (a few)
by Matthias Jordan 25 Jun '03

25 Jun '03

Hi, folks! I'm maintaining a private Phase-III installation and managed to set the whole thing up at last (with a customized language file, skin and some added functionality), but I still have some questions: + Is there /any/ documentation that covers admin issues besides of the source code? If so: where? I searched Wikipedia, the Meta-Wikipedia and this mailing list but didn't find anything that answers my questions. In particular, I'd like to know: + Is there a way to put the Wiki into a "write-only-if-you-are-logged-in"-mode? + Is there a way to put the Wiki into a whitelist mode (i.e. disabling users from getting an account without the agreement of the admin)? + What privilege concept does Phase-III have? What is the difference between a plain user, a sysop and a developer in terms of user_rights? + I have some ideas of features that would be nice to add. One of these is a user configurable default set of namespaces to search for. In Wikis for small communities that are only just evolving many users will want to search for some documentation which can only be found by searching for the keyword, failing and then selecting the proper namespace (which the user probably doesn't know). I hardcoded this mechanism into my setup but this is far from being a Good Idea (TM). What's the procedure to become a developer with write access to the CVS repository and to convince the other developers to be allowed to include certain features? Thanks in advance and bye! Matthias

3 2

Re: please accept patch for @@@ == [[user_talk:username]]
by Brion Vibber 25 Jun '03

25 Jun '03

Hunter Peress wrote: > to deny this patch by saying that this is merely a hack and that a > overhaul to the talk pages is needed, well....then i *demand* that you > deny it with code for your suggestion in hand. Attached is my proposed patch which tries to go for the root problem by making a more prominent link to edit the user talk page from a user page. This gives the same number of clicks to get into editing (one click to the user page, a second to edit the talk page), and works on all existing and future user page links. It's running on test.wikipedia.org right now. The exact look and feel could use some improvements, of course. I've not yet put it in CVS. -- brion vibber (brion @ pobox.com)

1 0

please accept patch for @@@ == [[user_talk:username]]
by Hunter Peress 25 Jun '03

25 Jun '03

this is a patch for @@@ == [[user_talk:username|username]] @@@@ == [[user_talk:username|username DATE]] just like ~~~ and ~~~~ usertalk is a better thing to leave as the system notifies people when their talk page is changed. thus communications are more smooth. to deny this patch by saying that this is merely a hack and that a overhaul to the talk pages is needed, well....then i *demand* that you deny it with code for your suggestion in hand. Patch: --- Article.php 2003-06-09 14:16:38.000000000 -0500 +++ a.php 2003-06-25 02:07:56.000000000 -0500 @@ -1506,11 +1506,19 @@ $d = $wgLang->timeanddate( wfTimestampNow(), false ) . " (" . date( "T" ) . ")"; if(isset($wgLocaltimezone)) putenv("TZ=$oldtz"); - + + #eg [[User:username]] $text = preg_replace( "/~~~~/", "[[" . $wgLang->getNsText( Namespace::getUser() ) . ":$n|$k]] $d", $text ); $text = preg_replace( "/~~~/", "[[" . $wgLang->getNsText( Namespace::getUser() ) . ":$n|$k]]", $text ); + + #eg [[User_talk:username]] + $text = preg_replace( "/@@@@/", "[[" . $wgLang->getNsText( + Namespace::getTalk(Namespace::getUser()) . ":$n|$k]] $d", $text ); + $text = preg_replace( "/@@@/", "[[" . $wgLang->getNsText( + Namespace::getTalk(Namespace::getUser()) . ":$n|$k]]", $text ); + __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

Mailing lists
by Jason Richey 25 Jun '03

25 Jun '03

There has been some recent discussion about upgrading our mailing list software. Also, we have discussed moving our mailing lists to a different server. I have upgraded the mailman installation on one of Bomis' servers, and have received the go-ahead from Jimmy for putting the wikipedia lists on that server. So, I'll be looking at making a switch in the next few days, assuming nobody comes up with a really good reason not to. -- "Jason C. Richey" <jasonr(a)bomis.com>

1 0

SQL queries logged
by Brion Vibber 24 Jun '03

24 Jun '03

Since there's been concern from some quarters about the effect of sysops' SQL access, I've rigged up AskSql so it logs the date, user, query, and length of time taken for queries. The log for the English wiki can be grabbed at: http://www.wikipedia.org/upload/sqllog_mFhyRe6 -- brion vibber (brion @ pobox.com)

2 1

some new CSS styles for images
by tarquin 24 Jun '03

24 Jun '03

I'd like to add some CSS classes to our stylesheets, based on the popular image layouts listed on this page: http://www.wikipedia.org/wiki/Wikipedia%3AImage_markup_gallery For example, instead of this: ------------ <div style="float:right;margin:0 0 1em 1em;">[[Image:image name|alt text]] ''Caption''</div> ------------ we could write this: --------------- <div class="floatright">[[Image:image name|alt text]] ''Caption''</div> ------------------ and the style rules would be in our stylesheet as: div.floatright { float:right;margin:0 0 1em 1em; } div.floatright p { font-style: italic; } Advantages: 1. easier to type for contributors 2. less "evil" code in the wiki text. It's easier for the average reader to understand what the "evil" code does. 3. we have built-in formatting for captions which is applied consistently across all pages 4. when we switch to a markup such as: "{{floatright}}[[Image:foo]]", the css is already in place and the way rendered pages look will not change. 5. we can easily choose to apply borders to all our images, or a soft background color. I propose to add: 1. float right, as above 2. float left 3. centered block 4. "gallery", see the example in the attached document

4 9

Re: [Wikitech-l] A proof (was: CJK Revision diff -- Vanadalism Detection)
by Menchi Zh-En WP 24 Jun '03

24 Jun '03

>From: "Menchi" ... >2) The following example is even more bizarre. There's no space added, no >char changed, but yet 3 sentences were reddened: > >http://zh.wikipedia.org/w/wiki.phtml?title=Wikipedia:%E5%B8%B8%E8%A7%81%E9%… > >Such difficulties renders what could be obvious vandalism in Western >Wikipedias quite subtle in CJK Wikipedia.s > >Menchi Zh-En Ok, after the 6 inspections of that Chinese Wiki-diff -- 1 of which C-&-P'ed to Notepad, another to Word -- I gave you above: I found the difference, finally. It is a vandal (and I honestly thought just a newbie wanting to perfect our Mandarin wording! I mentioned vandalism merely as a possibility). The vandal changed the mentioning of the English WP creation year fr. 2001 -> 2006. A moronic joke or Anglophobist it is. Anyway, that just further proofs the flaw of the current diff detection. Menchi Zh-En _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

CJK Revision diff -- Vanadalism Detection
by Menchi Zh-En WP 24 Jun '03

24 Jun '03

The revision history diff is impossible difficult to read, unless you possess an android eyeball. 1) If somebody changed a single CJK char, _several_ sentences around it became red (until both edges encounter a non-CJK character) in the diff. 2) The following example is even more bizarre. There's no space added, no char changed, but yet 3 sentences were reddened: http://zh.wikipedia.org/w/wiki.phtml?title=Wikipedia:%E5%B8%B8%E8%A7%81%E9%… Such difficulties renders what could be obvious vandalism in Western Wikipedias quite subtle in CJK Wikipedia.s Menchi Zh-En _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Something is wrong with our edit box on IE 6.0
by Axel Boldt 24 Jun '03

24 Jun '03

As an anonymous user with IE 6.0 (I haven't tried 5.5), go edit a page whose wiki source contains a very long line. Initially, everything looks good, the edit box fits into the browser window, you have a vertical scroll bar to the right of it, and the long line is broken into pieces and completely visible. Now when you type anything, the scrollbar goes away and the edit box extends to the right to accomodate the long line; there is no horizontal scroll bar and there is no way to view text near the end of the long line (short of buying a monitor of Times Square proportions and enlarging the browser window). Axel __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

Re: Many things
by Brion Vibber 22 Jun '03

22 Jun '03

> > Subject: > [Wikitech-l] search in spanish wikipedia is not workin > Fixed. > ----- The following addresses had permanent fatal errors ----- > <wikidown(a)wikipedia.org> > (reason: 550 5.1.1 <wikidown(a)wikipedia.org>... User unknown) Should be wikidown(a)bomis.com; this is now set in LocalSettings.php (it used to be hard coded), I've corrected it there. >Brion goes on vacation and everything starts to fall apart. First order of >business of the Wikimedia Foundation is to set up a fund to clone Brion. :-) > Hey, that could be fun. :) >There must be something like > > set-variable = max_connections=somebignumber > >in mysql.conf. > At present my.cnf has: set-variable = max_connections=560 vs Apaches': MaxClients 175 (on pliny) MaxClients 200 (on larousse) so we might have at most 375 apache processes attacking us at once. However, they might each take two mysql connections -- if the persistent connection is broken, it can't be closed (at least from PHP) short of killing the process, so it just opens a second non-persistent connection. And, in theory, we might see a handful more from SQL queries, which open another connection using a separate user for restricted permissions. We could probably do with lowering the max apaches on pliny a bit and upping the max connections on mysql a bit just to keep that particular part from blowing up; however if they are blowing up, that's going to be a symptom of something else... > We do dynamic gzipping of pages on a rather large website (~3.000.000 > dynamic hits daily). The experience we gathered so far showed us, that > the gzipping itself is actually rather fast, compared to the page > generation process through PHP/Perl. The main problem with dynamic > gzipping is, that you have to build up the whole page in memory, > instead of sending out lines as they are generated (don't know, how > the Wikipedia software currently works). Currently the page is output in several chunks, but usually the majority of it is the wiki page itself, which is processed (over and over and over) and eventually output as one chunk. The other chunks are in the headers and footers, generally. If we're generating a newly cachable page, we turn on complete page buffering and capture the buffer to save it to disk (gzipped and not). There are, of course, improvements that can be made to our parser... -- brion vibber (brion @ pobox.com)

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2003