Page MenuHomePhabricator

Non-ascii characters in article titles messed up on upgrade from 1.11 to 1.15.1
Closed, DeclinedPublic

Description

Author: a.s.lovlie

Description:
I just upgraded my wiki project from 1.11 to 1.15.1. I did it by re-running the install script, since the command-line php client on my server is 4.3, not 5. Once the upgrade was done, all non-ascii characters in article titles where messed up. I did not conciously change the encoding for the database (didn't make a choice, since the install page says it is ignored on updates).

Furthermore, I notice that when I point my browser to the new mediawiki config folder, without having run the script first, the link that says "Please set up the wiki first" points to config/index.wiki, not to index.php. It also doesn't give a good error message if you by any chance have the permissions of the config folder set to 700 (which I have, because I am linking in a wiki family setup of this kind: http://www.steverumberg.com/wiki/index.php?title=WikiHelp_-_Method_Two )


Version: 1.15.x
Severity: major
OS: Linux
URL: http://en.textopia.org

Details

Reference
bz20831

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:50 PM
bzimport set Reference to bz20831.
bzimport added a subscriber: Unknown Object (MLST).

Try disabling $wgDBmysql5 in your LocalSettings.php; that should emulate the previous connection behavior. (Or else turn it on if it was off.)

a.s.lovlie wrote:

(In reply to comment #1)

Try disabling $wgDBmysql5 in your LocalSettings.php; that should emulate the
previous connection behavior. (Or else turn it on if it was off.)

Thanks for your suggestion! However I have a limited number of articles in my wiki (ca. 100), so when no-one responded to me on the irc channel, I just went in and fixed each messed up title manually. So now I don't think I can verify whether this fixes the issue... Just wanted to report it as a bug in case i helps the development.

Assuming that this is similar to bug 38250, did you check which encoding your database is set to? If it's for example latin1 encoding but should be utf8 that might be the reason. And bug 29731 also might be similar.

It looks like you've fixed the problem in the meantime anyway, so I'm closing this as WORKSFORME for now. :-/