For those who use old query.php API interface:
Per http://bugzilla.wikimedia.org/show_bug.cgi?id=12881 , query.php has been
fully ported to the api.php, and thus no longer needed. Unless there are
significant reasons to keep it around, it will be removed both from the
extensions and from the mediawiki sites fairly soon.
If you are still using it, see http://www.mediawiki.org/wiki/API description
on how to use the new api.php.
Thanks for all the support!
I tried to upgrade a couple Wiki's from 1.10 to 1.11.1 but it didn't go
exactly how it says... I'm not sure the database changes
How can I be sure?
I was doing these steps from
Alternative 2: Re-run the installer
An alternative to running the update script from the shell is to re-run the
web installer. To do this:
1. Rename LocalSettings.php to LocalSettings.old.php
2. Make the config directory writable by the web server
3. Make sure the database user has full rights to the database
4. Browse to the wiki and start the installer
Fill in the form fields with the same values as was done during the previous
version's installation. When the installation process
starts, the script will detect existing MediaWiki tables, and upgrade their
schema. When this is complete, a new LocalSettings.php
will be generated.
1. Delete the new configuration file
2. Rename LocalSettings.old.php back to LocalSettings.php
3. Restore permissions on the config directory
The issue is that I never saw it run through the installer.. there were no
form fields. It just created the new LocalSettings.php
file and it seemed to know all the right settings somehow without me telling
Anyway, it seems to be working fine and OK, I just want to verify the
"schema" was actually upgraded. Any suggestions or clue I
should look for in phpMyAdmin to made sure the database tables were
I'm having a problem with my installation regrading the use of accented
characters (actually it appears with any non-ascii character). I
suspect perhaps a DB setup error, though I cannot determine what it is,
or how I would fix it.
If I use a non-ascii character on a page it displays fine, so long as it
is not followed by further text (that is, if followed by a blank or
newline). As soon as the character is followed by another character it
The page I am trying is: http://wiki.disemia.com/Sandbox
It has the corrupted data in it, the pretext and posttext both should be
I took the same source (before corruption) and tried at the mediawiki
sandbox and had no problems (likely eliminating browser error).
Using wget I got the contents of that page and see that the first ü's
are encoded correctly for UTF-8 (C3 BC), the corrupted ü is encoded as
(EF BF BD).
According to RELEASE-NOTES I am using MediaWiki 1.11.0
MySQL: Server version: 5.0.45 FreeBSD port: mysql-server-5.0.45
PHP 5.2.4 with Suhosin-Patch 0.9.6.2 (cli) (built: Oct 4 2007 18:22:07)
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.
i ran a aptitude upgrade and since this moment tex doesn't work anymore
i get a math_image_error
apparently tex can't find the latex-path with article.cls, defined by
the env variable texinputs
i don't know where to set it and to what to make it work again
thanks in advance
this is the logoutput
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=latex
2007.3.1) 2 FEB 2008 13:39
entering extended mode
%&-line parsing enabled.
Babel <v3.8d> and hyphenation patterns for american, french, german,
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
kish, ukrainian, nohyphenation, loaded.
! LaTeX Error: File `article.cls' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: cls)
Enter file name:
! Emergency stop.
*** (cannot \read from terminal in nonstop modes)