Opened 15 years ago
Last modified 6 years ago
#13103 assigned defect (bug)
"Unknown character set" during install into database reports successful install.
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Database | Keywords: | has-patch needs-refresh |
Focuses: | Cc: |
Description
During editing of the wp-config.php, I changed
define('DB_CHARSET', 'utf8');
to
define('DB_CHARSET', 'utf8_general_ci');
Which I thought was valid.
After clicking "Install Wordpress" I got a page full of:
WordPress database error: [Unknown character set: 'utf8_general_ci']
And at the bottom, "Success" with a login prompt, but nothing was actually created in the database.
I think WP shouldn't report a successful install if the user happened to accidentally change this value (or another) during install as it would cause confusion.
I used a svn checked out version of WP on 2010-04-24 on my local computer using PHP5 and apache2, but I think this is really a problem since 2.6 (or when the current install system was implemented).
Attachments (2)
Change History (16)
#1
@
15 years ago
- Keywords needs-patch added; install error database removed
- Milestone changed from Unassigned to Future Release
#4
@
13 years ago
- Keywords has-patch added; needs-patch removed
This is my first patch so please tell me if I did anything wrong in Trac :)
#5
@
12 years ago
- Component changed from General to Upgrade/Install
- Keywords needs-refresh added
- Priority changed from lowest to normal
- Severity changed from trivial to normal
#7
@
12 years ago
__('The charset \''.DB_CHARSET.'\' set in wp-config.php, is not available in your database.')
This is not localizable, sprintf()
should be used instead:
http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/
#8
@
12 years ago
New patch uploaded.
Installer is now checking Database collation before the user can fill in the form, because he will not be able to install WordPress if the collation is wrong anyway.
#11
@
12 years ago
Tested 13103.patch and it prevents me from starting the install as expected with a bad DB_CHARSET. Looks good for me.
#12
@
12 years ago
- Component changed from Upgrade/Install to Database
- Milestone changed from 3.5 to Future Release
I'd like to test this some more. A false negative could result in people being unable to install WordPress, which is not good.
#13
@
12 years ago
A couple of thoughts:
SHOW CHARACTER SET
was added in 5.0.3 - do we want a version check in wpdb::has_cap()
for that?
I suspect it may be possible to configure a MySQL server such that SHOW CHARACTER SET
performs a case sensitive search, even though the related server variables are case insensitive. Ie, the following query fails:
SHOW CHARACTER SET WHERE Charset COLLATE 'utf8_bin' LIKE 'UTF8';
The query would allow for that as:
$wpdb->prepare( 'SHOW CHARACTER SET WHERE LOWER( Charset ) = LOWER( %s )', DB_CHARSET )
utf8_general_ci
is not a valid charset (Character Set), What it is, Is a valid collationYou can set the Collation via the constant DB_COLLATE, but the charset should stay as 'utf8'.
The installer should reconise failed SQL queries however, I'm not sure why it doesnt already.
Future Release pending patch.