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
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)
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
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>
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)
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
>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
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
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
>
> 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)