I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/)
and I need to extra the content from it and convert it into LaTeX
syntax for printed documentation. I have googled for a suitable OSS
solution but nothing was apparent.
I would prefer a script written in Python, but any recommendations
would be very welcome.
Do you know of anything suitable?
today we came over 10k HTTP requests per second (even with inter-squid
traffic eliminated). Especially thanks to Mark and Tim, who've been
improving our caching, as well as doing lots of other work, and
achieved incredible results (while I was slacking). Really, thanks!
>From the latter, we have
"Two users who started their first-time editing with a paragraph
instead of the whole page were not confused by the syntax. However,
they were faced with another problem: The location of the "Edit" links
seemed to relate them with the paragraph above, not the one below.
Therefore, when clicking the "Edit" link below "Geschichte", they
expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the
editor window. They were confused, did not know what to do. Finally,
both participants deleted (!) the existing and valid text, and started
to add their own text."
We've known for well over a year now that this is a problem. I would
like to finally fix it. Specifically, I intend to remove the
editsection float style, so it's at the beginning of the section line,
to the left. The alternative is to have it as the German Wikipedia
does, with the section edit link on the right of the header; however,
this a) is kind of annoying as the link jumps around, and b) requires
a change to the document structure (admittedly just a reordering of
elements, but it may well break some fragile stuff regardless). It
does arguably look better, though, and that could be done instead
(opinions?). A comparison of the three styles is available at
Before this goes into effect, it would be only courteous to inform
existing wikis about it and the reasons for doing it. I'll prepare a
little message and get someone with bots everywhere (Yurik?) to post
it on all the wikis' MediaWiki talk:Common.css pages, I think, before
I commit it, and so well before it goes live, along with instructions
on how to reverse it preemptively if desired.
Are there any objections to this?
It's been some time since we've expanded our server configuration at
wikiHow. We currently have 5 servers (1 Squid, 3 Apache and 1 DB) and
I have some questions about planning for future growth. We do make use
of memcached and eaccelerator, Squid occasionally reaches 300 requests
per second, and we get about 5.5 million unique visitors a month
growing at about 10% per month. All servers are dual Opteron 64bit,
4GB of RAM, with 3x73GB SCSI drives.
Does anyone know how it's possible to estimate how much available
cushion there is for a given Apache server? Is there an upper limit on
the number of requests per second or server load? Basically, at what
point can you be sure that you need to add more Apache servers?
The ratio of Squid to Apache server should be about 1:10, correct?
Once you add a 2nd Squid, what the best way to load balance between
the 2?DNS round robin or use a hardware load balancer?
When should a 2nd database server should be added? Are there any other
optimizations we could be benefiting from?
If anyone has any input, it would be much appreciated.
Sorry for my complete ignorance, but because I am unsure if this is a bug on
MediaWiki or simple the need to poke sysadmins to take a look at the s3
cluster more frequently, I am reporting this here.
A n00b at Portuguese Wikisource had decided to insert a brazilian salutation
slang in the second most used template on that wiki for unknown reasons. A
admin with poor English (me) reverted it. . All have happened 9 days ago
but since it the job queue is floating between ~1,080 / ~2,400. What is
While browsing UseMod, as I almost never do, I came across the
following interesting comment on
"Several wiki engines have agreed to jump on board (including
MediaWiki and the Ward's original WikiWikiWeb)."
We have, have we? I was under the impression that we couldn't even
standardise our own markup, let alone support something else; I also
got the impression from the recent discussions in response to the
"announcement" that several developers did not see a significant
benefit in supporting it.
The question, then, is where this impression came from, and whether it
is correct; I'm directing this one at the release manager (Brion), and
his senior assistant (Tim). If the impression is false, then who on
Earth expressed this support?
I hate to be obstinate with this, but according to the results on:
The 7zip pages-meta-history.xml dump for enwiki is 3.2GB and OK. On 11/06 it was more than 8 GB long, so I think we still have a BIG problem to solve about that...
I hope that someone could be so kind to answer this message, not like the previous one that, apparently, arrived to nowhere...
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!.
After a brief planning discussion with Tim a few days ago, I'm
re-working the Title::userCan method. Once I'm done, and after code
review, on failure, the method will return, instead of false (although
that will still be returned for unexplainable events) an array
consisting of a message name, followed by a number of parameters which
are the arguments to the message. For example, being unable to edit
due to a block will return:
array ( $block->mAuto ? 'autoblockedtext' : 'blockedtext', $id,
$reason, $ip, $name, $blockid, $blockExpiry, $intended );
And being unable to edit due to cascading protection will return:
array( 'cascadeprotected', array_len( $cascadingSources ), $pages );
The purpose of these changes is to streamline the way access failures
are reported to the client. Currently, if userCan returns false, a
correct error message is guessed by the calling method. After these
changes, the message will be generated when the access failure is
detected. In addition, this method will be the only method that needs
to be called in order to ascertain whether a user can perform a
specific action on a specific page: block checks, readonly checks, and
other stuff is being folded into it, too.
This alteration is part of an effort I'm putting in to clean up and
streamline the permissions system.
Questions, comments, objections, abuse, and other feedback is welcome,
and will be appreciated.
I may have asked this question before, but:
Is there anyway to filter which cookies are subject to the 'Vary'
header in Squid or through HTTP response headers?
We'd like to use Google Analytics (as AWStats isn't working well for
us), but it cookies users making the caching system pretty much
useless. If we could ignore cookies that start with __utm, we could
likely use both.
Does anyone know? Or know of another way around this to accommodate
both Squid and Google Analytics?