Package Management: 'Not Installed' Status remains after package installation.

To prevent charset problems, the DB, the tables, the fields in the tables, and the data in the fields, should all be in the same character set. It doesn’t always happen.

This might help you: http://bobsguides.com/convert-db-utf8.html

thanks for the reply bob, youre great (:

but what i’m experiencing is not an issue of wrong character set at the database.
the date is stored normaliy as it should in the db tables.

my problem was with the differnce between character sets on the local server machine set to foreign language and the modx site which configured as UTF8 as same as the database, ENglish site as i wanted to be and will be up over my web server.
i bypassed it by adding setlocale(LC_ALL, ’english-us’); in the top of my snippet, to get the right date in english.

but as you can see on the top of the topic the problem effects dates in the back-end interface so i wonder if i need to add this ’setlocale’ definition just to get it right, just because my testing platform is set on different local language, i think modx should overcome this.

once again, thanks

I can’t help you there. Hopefully, someone else will chime in.

setlocale solves the problem, when i use a snippet with it even just once it fixes the manager as well.
the question is why isn’t it a part of the language settings in the manager

i must say i wasn’t sure therefor i didn’t know if i should report a bug


and what about using another setlocale definition? then i need to use iconv function as i mentioned before?

I’m throughly confused, as setlocale should not affect the data at all. Sounds like you are storing non UTF8 data as UTF8, and that is the only problem.

setlocale (from the php.net manual)

setlocale — Set locale information

Note:
On Windows, setlocale(LC_ALL, ’’) sets the locale names from the system’s regional/language settings (accessible via Control Panel).

Return Values Note:
The return value of setlocale() depends on the system that PHP is running.
It returns exactly what the system setlocale function returns.

As i mentioned before, i’m experiencing this messup on my local testing platform.
OS: Win7 | Server: XAMPP 1.7.3.
The MySQL db charset is set correctly to utf8 (utf8_general_ci).
The data that is showing wrong is not from the database as i understand, it’s the regional/language names given to the date functions by the OS (by windows).

lets say for example i was fine with the local regional settings of my server, then
when given (in the regional/language name from the OS, in whatever charset is to be) it’s outputting question marks, and then iconv function is needed to show it in the right encoding of the regional name.


maybe adding a new setting for the setlocale(locale information) in the manager will be more bulletproof for this kind of issues?


hope i explained it clearer.
i feel like i’m saying the same over and over again sorry for that.

setlocale has no affect whatsoever on the dates stored in the database, so I’m still confused. This only affects how they are displayed.