#27333 closed defect (bug) (invalid)
update_option() truncates the option value
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.8.1 |
Component: | Database | Keywords: | |
Focuses: | Cc: |
Description
When updating an option with a value which contains a special character the value is truncated (example: I tried to insert 'testºthis' and I ended up with only 'test' in the database).
I noticed replacing define('DB_CHARSET', 'utf8'); with define('DB_CHARSET', 'utf-8'); fixed the issue.
Is there a reason 'DB_CHARSET' is set to 'utf8' instead of 'utf-8' ?
Change History (4)
#1
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
11 years ago
- Component changed from General to Database
The character here is a 2-byte masculine ordinal indicator, so #13590 and #21212 appear to be irrelevant.
I could not reproduce the issue. My steps:
- Save these lines to a file encoded in UTF-8 and run it:
include 'wp-load.php'; add_option( 'test', 'testºthis' ); // echo get_option( 'test' ); // delete_option( 'test' );
- Comment out
add_option()
and uncommentget_option()
(to make sure the result comes from the database and not from cache). - The result is
testºthis
. - Uncomment
delete_option()
to delete the option.
If the string comes from a file in your case, make sure it's encoded in UTF-8 (without byte order mark). If that doesn't help, try inserting the same string with phpMyAdmin to see if the database charset is correct.
Note: See
TracTickets for help on using
tickets.
"utf-8" isn't a valid MySQL charset, so I imagine it gets treated as the default charset, like latin1 which will accept anything.
For special four-byte multibyte characters, you can use "utf8mb4" as a charset. See also #21212.