RC4 install fails: can't connect to db

I’m still looking at this in between other things, it works OK on my windows box using PHP 5.3.1, on the PDO instantiation we send ’charset=’ and it comes back as ’charset=latin1’ with no error. I’m guessing that on my linux box which uses PHP 5.3.6 we have to set charset equal to something, i.e send ’charset=utf8’ and it’ll return as whatever the charset is. I’ll try this later when I have the box in front of me.

I don’t even see UTF-8 in my charsets

maybe that is it? of course 2.0.8 install works fine but its 2.1

Same issue here, and UTF-8 is also missing in /usr/share/mysql/charsets (Revo 2.1, CentOS 5.6, php 5.3.6)

It doesn’t exist in my MAMP installation either, although the reference I posted above does exist in the index.xml file. I presume that utf8 is some kind of default that doesn’t need further definition.

My suggestion was just a general thought based on the error message given. I don’t know Revo and how it works, so it’s probably not relevant to the actual issue.

[edit] Found out why there’s no .xml file for utf8 (utf8 is a multibyte charset).

Compiled in or configuration file?
When should a character set be compiled in to MySQL’s string library
(libmystrings), and when should it be placed in a charset_name.xml
configuration file?

If the character set requires the strcoll functions or is a
multi-byte character set, it MUST be compiled in to the string
library. If it does not require these functions, it should be
placed in a charset_name.xml configuration file.

If the character set uses any one of the strcoll functions, it
must define all of them. Likewise, if the set uses one of the
multi-byte functions, it must define them all. See the manual for
more information on how to add a complex character set to MySQL.

OK, hacked the initial connection dsn to be ’charset=utf8’ as opposed to ’charset=’, works now, collation is set from the database in question in the dsn as in other versions of PHP. Installation is fine after this. Bug raised http://bugs.modx.com/issues/4865. Not checked on MSSQL yet nor have I tried to not set charset at all.

It may be PDO here as opposed to PHP I suppose but this is a stock install on F13, we should cater for this.

Quote from: shamblett at May 26, 2011, 05:14 PM

OK, hacked the initial connection dsn to be ’charset=utf8’ as opposed to ’charset=’, works now, collation is set from the database in question in the dsn as in other versions of PHP. Installation is fine after this. Bug raised http://bugs.modx.com/issues/4865. Not checked on MSSQL yet nor have I tried to not set charset at all.

It may be PDO here as opposed to PHP I suppose but this is a stock install on F13, we should cater for this.

how can i do this "temporarily" until its figured out.. i have other bugs and stuff i want to test with a fresh install but at this point i can’t even do a fresh install till this is resolved.

Hi,

Same issue here. My temporary noob solution was to do a clean install of 2.0.8-pl and then upgrade to 2.1-pl.
I know it doesn´t solve the bug, but at least the impatiently curios can have a sneak peak.

Shamblett, can you please explain what you did to get around the problem?

Yes, it was a bit of a hack and I wouldn’t recommend doing this but what I did was this :-

Just above line 341 of XPDO.class.php add this :-


This will get you past the collation stage and get your correct collation back, DON’T press the next step which is ’connect to database’ or something like that.

Comment out the code you’ve just put in(or restore your original file).

Now press the connect to database link, should be good to go from here.

There’s probably a much better place to do this in the setup code, you just need to default the charset to utf8(or any valid one I suspect) I just didn’t have time
to look further.

It may be worth looking at the bug, the real fix may have been done.

FYI, I updated MacPorts to PHP 5.3.6 yesterday and am working on the issue today...