After upgrade, character encoding is broken
After upgrade, character encoding is broken
I upgrade to DT 1.13.10 (from a 1.9.x version) and after that, my production site's character encoding is broken. My local instance is just fine, I did the tests and then moved to production but non-Latin characters like ö, ş show up like "�", therefor breaking the JSON encoding which results in empty table.
I have charset => 'utf8'
in $sql_details
but it doesn't do the job. (Actually I had utf8mb4 for years but I also tried utf8 now.) Interestingly, manually putting $db->exec("set names utf8");
in ssp.class.php resolves it. I have DT Editor 2.0.8 in another page on the same production site, it continues working fine.
So what could be the reason and how to natively resolve it?
Answers
You might need to do:
before using the
Editor::inst()
constructor. It really depends on the PHP and MySQL setup if it is needed or not.Allan
Thanks Allan. You might miss that I already said I did that in ssp.class.php and it worked. I just wonder why I needed this while especially I already have the charset in connection string. As for the Editor, it is just working fine. Only DT instance is breaking the encoding. I find it interesting that;
1- My PHP and server settings didn't change. I just updated DT files. Why would the encoding change all of a sudden?
2- My production site has a page with DT and has another page with DT + Editor. How come DT + Editor works fine but the other page which has only DT is used broken. It is actually a single project which uses the same files to display the tables in different pages.
I was a bit confused about the ssp.class.php part. The first part of your post suggests that you are using Editor? You typically wouldn't use the ssp.class.php file as well as Editor's PHP libraries, since they provide far more flexibility than the limited demo of the ssp.class.php file.
Without being able to debug the server, I don't I'm afraid. I guess something in the database connection setup I use changed, but I don't recall what that would be.
I also don't know that without being able to debug it. Sorry.
If you need
set names utf8
, then that's fine - some database connections do need that. You could call it in ssp.class.php and after the Editor PHP libraries have been included (although again, I don't understand why both would be used).Allan
Sorry if I couldn't make it more clear. It is because:
In my application, I have a page which lists the company's products, a page which allows editing the product information. This page obviously loads both DataTables and Editor (but doesn't use ssp.class of course). And the application has also a page for displaying the application logs, which obviously doesn't need editor and it uses just DataTables. (Here comes in ssp.class)
The products page, without running any
set names utf8
command displays the UTF8 chars correctly, whereas the very same database and the same server breaks the very same chars when loaded in logs page with spp.class.Ah! I'd just use the Editor class, but add a call to
->write(false)
- see this post. Means less code to maintain .There must be some kind of interaction from the
charset
that is causing the difference. That's the only thing I can think of that is different really.Allan
Sounds quite better, I will give it a shot. But as far as I can tell, client-side JS files to be loaded is still the same as with ssp.class right?
Correct
Allan