[Plugin: KC Settings] Term meta issues with encoding

Hello,

Unfortunately I cannot reproduce the collation bug. Every tables created by the plugin is UTF-8. Perhaps your database’s collation is latin1_swedish_ci?

If you’d be so kind, please go to your PHPAdmin page, click the database and then click the Operation tab. On the bottom of the page you’ll see the database collation. If it’s set to latin1_swedish_ci just change it to utf-8 and save the change. If not, please let me know.

If you changed the collation, you can delete the termmeta table and reload the Term editing page and try entering the Serbian letters and let me know the result.

Thanks.

Lets see what we have with collation in MySQL. When you open phpMyAdmin, you have MySQL connection collation. When you open database, then Operations, you again have Collation setting. You then have same for each table and you have collation of each row that you can set under Structure.

What I have is utf8_general_ci in dashboard, latinn1_swedish_ci for database collation and utf8_general_ci for tables and rows. This is default and this is how WordPress makes it and it works without a problem.

When you install KC Settings and when it creates table wp_termmeta it is with latin1_swedish_ci and this is source of the problem.

I solved it by deleting this table, changing database collation to utf9_general_ci, then activation plugin again which creates wp_termmeta this time with utf8_general_ci.

So what I think you should do is follow WordPress way of creating tables with utf8_general_ci even when table collation is latin1_swedish_ci. People don’t need to use phpMyAdmin for WordPress tables, why they should use for KC Settings?

Thank you for your plugin and your reply.

Well, if you take a look at the term.php file, you’ll see that I used a pretty standard WordPress way to create the table, which I got from the Simple Term Meta plugin and confirmed by the Codex.

Surely I’m no expert with SQL, but I’ve experienced this behaviour in WordPress and other PHP apps using MySQL (different collation for different table) when the database was not originally set to utf8. This could be the caused by (among other things) the operating system the database runs on (I’ve experienced this with my Gentoo Linux before I moved the whole system to utf8).