• Resolved endolith

    (@endolith)


    If I create special characters using the “Custom characters” button they are erased and turned into question marks as soon as I press Save. Shouldn’t WordPress be able to handle characters generated by itself??

Viewing 15 replies - 16 through 30 (of 38 total)
  • Thread Starter endolith

    (@endolith)

    In a default installation you should have these two lines in your config.php

    define(‘DB_CHARSET’, ‘utf8’);
    define(‘DB_COLLATE’, ”);

    I do, in wp-config.php

    define(‘DB_CHARSET’, ‘utf8’);

    define(‘DB_COLLATE’, ”);

    Your DataBase and all your tables should be utf8_general_ci and this is crucial for all of us using other than latin characters. Backup and then read the link i provided you.

    They are not, though, and they are not configured this way by default. Why not? My brand new installation is all latin1_swedish_ci.

    Thread Starter endolith

    (@endolith)

    I tried this plugin on my test installation:

    https://g30rg3x.com/utf8-database-converter/

    but any posts with special characters were destroyed. Are there any other solutions for this? Are there alternatives to WordPress that don’t have problems like this?

    Thread Starter endolith

    (@endolith)

    Oh wait. phpinfo has mbstring.internal_encoding ISO-8859-1, which is Latin1. Is that the fundamental problem?

    Thread Starter endolith

    (@endolith)

    Alright screw it. I only have 12 posts, so I backed up the SQL database, backed up the actual content of the posts by saving them as HTML and copy-pasting them into Google Docs, went through and manually removed any non-ascii characters I could find in the hopes that they will convert without corruption, and now I’m going to use the plugin even though it’s only for old versions of WordPress.

    Thread Starter endolith

    (@endolith)

    …. and most of the posts survived. Some were truncated, but whatever, I made backups.

    Thread Starter endolith

    (@endolith)

    Note: When backing up your website as HTML, don’t click “HTML complete”. Just “HTML”, or it overwrites your file paths. :'(

    Here’s a solution for your problem:

    1) Open wp-config.php;
    2) Find:

    define('DB_CHARSET', 'utf8');
    define('DB_COLLATE', '');

    3) Change it to:

    /*define('DB_CHARSET', 'utf8');
    define('DB_COLLATE', '');*/

    Cheers ??

    I changed my wp-config file to what Deusdies suggested and it worked great!! Thanks.

    After upgrading an old version of WordPress and separately doing a new install for 2.5.1 I am having the same problem with foreign language characters being displayed as question marks and weird symbols. All is fine when typing out the post, but the problem comes when it is saved…it displays the weird symbols after that.

    On the upgrade from the older version of WordPress, that install displayed the foreign language (Korean) characters just fine. The new install never has.

    I found info in another board that advised to just delete:

      define(‘DB_CHARSET’, ‘utf8’);
      define(‘DB_COLLATE’, ”);

    and when I did that, the Korean characters displayed perfectly. However, when I went to log in to administer the site I was locked out with error strings. The pages are visible, but I can’t log in. Then, as advised in the above post to this forum I changed the wp-config.php to this:

      /*define(‘DB_CHARSET’, ‘utf8’);
      define(‘DB_COLLATE’, ”);*/

    and now I can’t even get the page to display even before I try to login. Now I get this error message:

      c_html/blog/wp-includes/pluggable.php on line 694

    Any ideas? The site that was upgraded to 2.5.1 is at: mylivingstone.com/blog.

    Thanks!

    Sorry, for some reason the full error message didn’t post above. It is:

      Warning: Cannot modify header information – headers already sent by (output started at /home/mylivin/public_html/blog/wp-config.php:55) in /home/mylivin/public_html/blog/wp-includes/pluggable.php on line 694

    I just took a new wp-config.php file from WordPress and input the db info and the code from Deusdies and now it works fine. I guess somehow my wp-config.php file got corrupt.

    I’ve worked my way through all the fixes posted above with no success (I think I’m ok with the under-the-hood stuff but by choice would rather be driving ….).

    The situation is that in two separate new installs on two unrelated servers via Fantastico latest and cpanel latest displays only ????? when I post anything that my browser normally accepts as Hebrew utf-8. The situation is different on my wordpress.com blog: it works perfectly.

    Among the MySQL tweaks that I tried were:

    – changing the schema structure so that collation showed utf8_general_ci but the individual tables still showed latin1-swedish-ci

    – laboriously changing every char field (column) in every table to utf but the schema didn’t show any difference afterwards

    -making sure that all my default encodings in phpSQLAdmin were utf8 I created a duplicate database and imported all the tables and data from the orginal, only to find that char fields had determinedly stuck to latin1-swedish-c1

    – having tried the edits to config.php, in exasperation I’ve returned here to keep the topic open.

    My best guess at this stage is that server caching got in the way of all these changes. I cleared my browser cache several times to make sure.

    Any advice? besides sticking only to the wordpress.com subdomain, which is not the most efficient solution at this end.

    Thanks

    …via Fantastico latest and cpanel…

    This is what I WOULD DO if i were you:

    – Install a clean WordPress via FTP (dont mess with one click things)
    – Make sure your config.php has this settings (which are the default):

    define(‘DB_CHARSET’, ‘utf8’);
    define(‘DB_COLLATE’, ”);

    – After installation make sure all your tables are utf8 general_ci
    – Import what u got from WordPress.com or your backup

    It should work with no problems.

    Thanks – I’ll give it a go.

    define(‘DB_CHARSET’, ‘utf8’);
    define(‘DB_COLLATE’, ”);
    it works for me for upgrading to wordpress 2.7

    define(‘DB_COLLATE’, ‘utf8_unicode-ci’); is the problem. I guess wordpress 2.7 can identify this automatically.

    cheer

Viewing 15 replies - 16 through 30 (of 38 total)
  • The topic ‘Special characters converted to question marks on save’ is closed to new replies.