Upgrade to PHP 5.4.3 causes Fatal error: Call to a member function get() on a non-object in modmanagerresponse.class.php on line 41

In case it sheds any light, it was apparently the PHP upgrade that caused this issue. These are the server stats:

Apache version 2.4.7
PHP version 5.4.23
MySQL version 5.1.70-cll
Architecture x86_64
Operating system linux
Perl version 5.8.8
Kernel version 2.6.18-238.12.1.el5

Can anyone point me in the direction of wherever database connections are made? Only setup/includes/drivers/modinstalldriver_mysql.class.php uses mysql_connect (I thought maybe the default for the fifth flag for forcing the new 41 character password hash had changed).

To confirm, old_passwords is set to false and length(PASSWORD('abc')) returns 41, as it should. I'm unable to access the mysql.user table.

I also got this error (SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication.) rather than simply can't connect, when I tried manually appending "latin1" to the DSN string. Might an invalid DSN or connection string trigger this error or trigger a forcing of the old 16 byte password hash somehow on connect?

I've since removed the appending of latin1 but still get the "old insecure authentication" warning in the logs and when using a brand new core directory and empty database.

I've searched MODx to see if it overrides old_passwords but can't find anything. The server seems to set it to OFF.

Sorry for repeated posts. My hosts reckon it is because they're running Apache 2.4, and MODx specifies Apache 2.2 (http://develop.modx.com/develop/revolution/requirements/).

Any truth to this? It's true my dev server is running 2.2. Any solution other than change hosts?

Apache 2.4 has been the official release since November so would be a valuable patch for MODx although suspect too late for me - looks like I need another host.
[ed. note: technicaltitch last edited this post 10 years, 3 months ago.]

Quote from: technicaltitch at Jan 16, 2014, 11:51 AM

Sorry for repeated posts. My hosts reckon it is because they're running Apache 2.4, and MODx specifies Apache 2.2 (http://develop.modx.com/develop/revolution/requirements/).
Any truth to this?

None whatsoever - latest Evo & Revo are running just fine on Apache 2.4.7

Thanks very much for confirming Eoler.

(Editing this post rather than replying to thread to avoid filling inboxes.)

One more stab in the dark, but the server has PDO.

PDO Driver for MySQL enabled
Client API version mysqlnd 5.0.10 - 20111026 - $Id: e707c415db32080b3752b232487a435ee0372157 $

Quote from: technicaltitch at Jan 16, 2014, 12:26 PM

One more stab in the dark, but the server has PDO.
PDO Driver for MySQL enabled
Client API version mysqlnd 5.0.10 - 20111026 - $Id: e707c415db32080b3752b232487a435ee0372157 $

PDO or similar MySQL libraries client usually should have the same client API version as installed server, so it could be problematic that you are on 5.1.70/server with 5.0.10/client.

I got a bit pushy with the host tech support, and the passwords were indeed 16 byte (I couldn't access this myself). They fixed one, and it started working.

In phpMyAdmin the server reported that both the global and the session values for old_password were indeed FALSE. However changing the password in CPanel MySQL Manager left the password hashes as 16 byte (whether I used the same or a different new password or created a new user).

They acknowledged the client was too old so upgraded it and I'm now getting much better error messages, thanks Eoler.

So I need to ask my admins to change all my db user passwords, and to fix CPanel (version 11.40.0 (build 31), so not old, but perhaps customized/restricted).

Enormous thanks to everyone who patiently went through my many, many anxious posts and those that provided assistance.