The Mediawiki software has been presented in the "c't" magazine, a
(the!) important German computer magazine. It was recommended for large
wikis; the only drawbacks were the slightly complicated installation and
the rather plain appearance. Can't imagine why, though ;-)
Magnus
Evan wrote:
> >>>>> "BV" == Brion Vibber <brion(a)pobox.com> writes:
>
> Me> OK, so, I took my first crack at working on MediaWiki with an
> Me> attempt to check for cookies when logging in (bug #770011).
>
> BV> Great! I'm in the middle of the SoCal Linux Expo and will look
> BV> this stuff over when I get a chance... If some of the other
> BV> developers could look after this that'd be great.
I might have a quick look now.
>Coolio! The patches I submitted are all independent -- none depends on
>another, that I can see, nor should they conflict -- and made against
>the HEAD for phase3. Some use global variables, so I'm going to wait
>till they're applied (or rejected B-) before trying to jigger with the
>$REQUEST hoohaw.
>
>I'm going to try and cut my teeth on the transactions stuff. I
>figure I'll just try to find calls to wfQuery() with INSERT, UPDATE,
>DELETE in them, and wrap something like wfBegin()/wfCommit() around
>them, with wfRollback() for error conditions.
>
>I'll probably miss 20% of them, and screw everything up. Should be a
>fun time.
Missing 20% is a lot better than missing 100%, which is what we're doing at
the moment. It's really making a mess of our database, we often have to
clean up inconsistencies manually. So everyone will be eternally grateful.
But before you start, I have to make sure you know about the dangers of
transactions. These dangers were discussed by Brion and I on wikitech-l, in
mid-August 2003 under the subject "Using HEAP tables":
http://mail.wikipedia.org/pipermail/wikitech-l/2003-August/thread.html
Transactions have to be guarded against user aborts. This could be done
either with a "critical section" model, where user aborts are disabled for
the duration of the transaction, or alternatively a shutdown function could
be used. The shutdown function would rollback any active transactions.
However note that installing a shutdown function effectively disables user
aborts anyway. When there is a shutdown function, PHP only checks for
pending user aborts on output -- in our case, once per run.
If a PHP thread dies while a transaction is active, any locked tables will
remain locked indefinitely. The wiki will effectively become read-only until
a developer manually flushes the lock. We've seen this happen on the English
Wikipedia.
AFAIK, killing threads by restarting the webserver doesn't pose a risk,
because the MySQL connections will also be terminated, releasing any lock.
More information about user aborts is at:
http://www.php.net/manual/en/features.connection-handling.php
This discussion, and patch submissions, are probably more on-topic at
wikitech-l than at mediawiki-l. This post (and a couple of Brion's) have
been cross-posted there.
-- Tim Starling
_________________________________________________________________
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/mobilemania/default.asp
OK, so, I took my first crack at working on MediaWiki with an attempt
to check for cookies when logging in (bug #770011). I got all
flummoxed trying to upload the patch to SourceForge -- didn't you used
to be able to do that? -- so I'm just sending it here.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
So, I want to start making daily database dumps available on
Wikitravel. However, I don't want to give out user passwords or user
email addresses.
Is the script used by Wikipedia available anywhere? A quick review of
the MediaWiki codebase isn't coming up with anything. Ideas?
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
The following patch adds a Go button to Cologne Blue. It doesn't match
any existing bug; just a note on the Cologne Blue skin problems (great
name for a page, btw) meta page.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
Attached is a patch to reorder the links on the Cologne Blue
sidebar. I pretty much followed the suggestions on the bug page, with
several differences:
* I moved "Recent Changes" up to "Browse"
* I made Move, Delete, and Protect this page part of "Edit"
* I added "Post a comment" after the talk page link
I figured the Post a comment link was useful enough for all skins that
I added it to Skin.php as a method, commentLink().
The patch also fixes Bug #825774.
Lastly, the patch removes the ugly "Error" where "Delete this page" or
"Protect this page" would normally be, if the page doesn't exist
yet. I don't know if that's a registered bug or not; I don't think
it's much good, because it's not like the user made an error or
anything.
~ESP
P.S. I'm going to try to cut into some of the drudge work Brion was talking
about this weekend.
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
OK, so, I did some CSS goofing off, so that different types of links
(internal, external/interwiki, missing, stub) all have different
colors, whether they've been visited or not.
The colors are a little brash -- not terrible, but I think the
external unvisited one is kind of limey -- anyways, this can be
changed fairly easily. The mechanism is there to divide up the 8
different kinds of links, though.
I did this for all the skins, since as noted on the Cologne Blue skin
problems page, it'd be jarring to have different colors on different
skins. That can be changed, though. The mechanism should probably
remain, anyways.
Patch attached.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
So, I've been coming up with great ideas for MediaWiki -- or, rather,
great ideas for enhancements for MediaWiki for Wikitravel's needs. But
I figure it's probably going to be easiest to get into the code if I
start working on some bugs instead.
Are there any bugs that an interested volunteer could start working on
and submitting patches for? The huge list on sourceforge is a bit
much.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
Hello mediawiki-l,
Thanks to Brion, I managed it to install a mirror of the German
Wikipedia. To make it very simple, I configured the mod_rewrite
with the .htacces so that everything links to the printable
version. Since all the edit stuff isn't working anyway.
Sometimes, when I open a link, I get the link with a
?PHPSESSID=9308d65a897e0712a32cfd or something like that in the
end. How do I disable that? It makes the links longer, some search
engines wont spider me and I don't want to track my visitors.
My next question: I want to add a Google search form at the top
of every site (http://www.google.com/intl/en/searchcode.html#both)
I tried to just edit the LanguageDe.php since it contains the
static text on the sites, but it didn't work out. Is the
Skin.php the template? I couldn't figure it out how to add the
html code there.
Any help would be greatly appreciated!
--
Best regards,
Freerk mailto:freerk@gmx.net
--- Brion Vibber <brion(a)pobox.com> wrote:
> On Nov 19, 2003, at 19:23, Steve Cooney wrote:
> > But Im curious, for SP (or any other MW site) to
> use
> > MW, some specialized modules will have to be made,
> > some of which may not be useful to WP, but may be
> > useful for something else.
> >
> > Should imminently enthustastic and abundant SP
> > developers simply join MW, and get their works
> lost in
> > the shuffle, or can there be project forks in CVS
> > under the MW (still "Wikipedia" on sForge --they
> dont
> > do account transfers, eh?) that are modestly
> > independent and somewhat autonomous?
>
> We could add additional branches in CVS, but they
> would likely be much
> harder to maintain that way instead of just putting
> them right in the
> main dev branch, where people will test them and
> they have half a
> chance of getting maintained and going in the main
> stable distribution.
>
> Useful general-purpose stuff like SVG support and
> annotations should
> certainly go in the main code (and good features
> should also be easy to
> disable where not needed!)
>
> -- brion vibber (brion @ pobox.com)
Ok --but would it be better for MediaWiki if it had
some emphasis on its ability to branch out into
different, customized applications? By this, I mean
that, just as some have pointed out, MediaWiki aspires
to be more than just Wikipedia, and as such, people
will want use-specific packages, perhaps including
cut-down lite wiki versions (but with the benefit of
some newer bells and whistles). I know the whole thing
is actually pretty tiny anyway, though.
Just curious, because it seems to me that MediaWiki
wants to be more of an umbrella for other
non-Wikimedia wikis, and not just a one-trunk deal.
The difference is perceptual, but may effect how
MediaWiki recieves attention from freelancers, who
just want to find free sockets and new directions they
can plug themselves into.
Sincerely,
Stephen Cooney
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/