Hello, I have a couple of mediawiki installations on two different slices at
Slicehost, both of which run websites on the same slice with no speed
problems, however, the mediawiki themselves run like dogs!
http://wiki.medicalstudentblog.co.uk/ Any ideas what to look for or ways to
optimise them? I still can't get over they need a 100mb ini_set in settings
to just load due to the messages or something.
Thank you, Dawson
How is the api not documented? Between the docs on
Mediawiki.org and the fact that every parameter is
documented (with examples), I'd say its highly
documented.
-Chad
On Feb 1, 2009 12:18 AM, "Gerard Meijssen" <gerard.meijssen(a)gmail.com>
wrote:
Hoi,
Let us please appreciate what is being said here: "Wikipedia is a horrible
place to copy templates from". We pride ourselves of being open source and
the current templates make us as bad as the worst proprietary vendor. We
have what is effectively an API and it is not documented at all.
Thanks,
GerardM
2009/2/1 Daniel Friesen <dan_the_man(a)telus.net>
> ^_^ Wikipedia is already a horrible place to copy templates from. Unlike >
Wikipedia most other M...
Then that's solely enwikis fault for having poor docs.
If developers have documented where expected (in
code and on mw.org) then they've done their part.
-Chad
On Feb 1, 2009 12:33 AM, "K. Peachey" <p858snake(a)yahoo.com.au> wrote:
> How is the api not documented? Between the docs on > Mediawiki.org and the
fact that every paramet...
I think he means on wiki, most people probably won't know to look for
information on how to use it at the main/official mediawiki wiki and
just go by the scraps they can find on whatever local wiki they are on
(in this case en.wiki).
_______________________________________________ Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia....
Just as an FYI, wiki.freeculture.org has mis-encoded UTF-8 for the better
part of the past four years. This is because we used the old Latin 1
schemas.
Now we don't have these problems anymore. I wrote up my notes at
http://wiki.freeculture.org/Fixing_text_encoding_corruption , but here
they are for y'all's convenience:
1. freeze writes to the main wiki
2. Dump freecult_wikidb to dump.sql
3. Create a fresh MW install (just for the table schemas) in
freecult_wikidb2
4. Create a temporary empty DB, and import dump.sql to it
5. In the temporary DB, ALTER TABLE on the text table so it has the
same columns as freecult_wikidb2's text table
6. Dump wikidb3 and have certainty that the column names will line up
(but don't copy the sucky old schema)
* mysqldump --no-create-info --add-locks --complete-insert
freecult_wikidb3 > sql
7. Import that into freecult_wikidb2, skipping the tables that are
missing
* mysql -f freecult_wikidb2 < sql
* WATCH for errors other than "skipping missing table"
8. php maintenance/rebuildall.php
* If this fails with key errors, just drop the recentchanges
table and recreate it with the wikidb2 schema
I've poured enough of my life into this issue, but if someone else wants
to take this up and document it better, by all means go ahead!
-- Asheesh.
--
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"