After upgrade, character encoding is broken

pisisler

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?

allan

You might need to do:

$db->sql('set names utf8');

before using the Editor::inst() constructor. It really depends on the PHP and MySQL setup if it is needed or not.

Allan

pisisler

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.

allan

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.

1- My PHP and server settings didn't change. I just updated DT files. Why would the encoding change all of a sudden?

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.

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

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

pisisler

I don't understand why both would be used

Sorry if I couldn't make it more clear. It is because:

2- My production site has a page with DT and has another page with DT + Editor.

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.

allan

which obviously doesn't need editor and it uses just DataTables. (Here comes in ssp.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

pisisler

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?

allan

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