Forums / Setup & design / problems with eZ 3.6.1

problems with eZ 3.6.1

Author Message

Marko Žmak

Thursday 18 August 2005 3:14:40 pm

I've upgraded from eZ 3.5.1 to ez 3.6.1 and I have several problems. First I found out that the links from XML fields are missing. I found the sollution (convertlinks.php scripts), but couldnt run it.

Then I found aout that the Users section is badly displayed. There are no users and I found this under Subitems:

The <User group> class is not configured to contain any sub items.

Then I wanted to run updateiscontainer.php but this script also couldn't run. Next thing I found out that all the update scripts generate the same error:

Fatal error: eZ publish did not finish its request
The execution of eZ publish was abruptly ended, the debug output is present below.

and no other information (even nothing in logfiles!). I described in details this problem in the last post here:

http://ez.no/community/forum/setup_design/problem_with_links_ez_3_5_1_3_6_1

Could someone help me with this? It's causing serious problems on my site.

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Daniel Guerrier

Thursday 18 August 2005 5:18:30 pm

How are you trying to run the scripts?

Marko Žmak

Friday 19 August 2005 6:40:27 am

I'm running the scripts from the shell an I tried to run them i many ways, the detailed description is in this other post I mentioned. Here's an example:

update/common/scripts/convertxmllinks.php -s devel_me

but I tried almost all other parameters, and also tried run them with:

php update/common/scripts/convertxmllinks.php -s devel_me

I did some more research and found out that the error occurs in file:

lib/ezdb/classes/ezdb.php

at this code:

include_once( $dbFile );
$className = $databaseImplementation . 'db';
$impl = new $className( $databaseParameters );
break;

on the line "$imp = new ...".

I printed out manually the values of relevat variables:

$className=ezmysqldb
$dbFile=lib/ezdb/classes/ezmysqldb.php

$databaseParameters[user]=myuser
$databaseParameters[password]=mypass
$databaseParameters[database]=mydb
$databaseParameters[use_slave_server]=
$databaseParameters[slave_server]=
$databaseParameters[slave_user]=
$databaseParameters[slave_password]=
$databaseParameters[slave_database]=
$databaseParameters[charset]=iso-8859-2
$databaseParameters[is_internal_charset]=1
$databaseParameters[socket]=
$databaseParameters[builtin_encoding]=1
$databaseParameters[connect_retries]=0
$databaseParameters[use_persistent_connection]=disabled
$databaseParameters[show_errors]=1

where 'myuser', 'mypass' and 'mydb' are actually the correct username, password and dbname for the databse eZ uses. It seems like the problem is in creating a new instance of "ezmysqldb" class, which probably involves digging deeper in "ezmysqldb.php" file in the same directory.

Maybe there's a problem with connecting to the database, but the whole eZ site is functioning normally, so it can connect to the database, only this scripts can't.

Could anyone help me futher?

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Marko Žmak

Friday 19 August 2005 7:06:47 am

I just found the source of the problem. When I run this script:

<?PHP

$connection = mysql_connect( 'localhost', 'medev', '2!zumbul!2');

echo $connection;

?>

in the shell I get this error:

Fatal error: Call to undefined function:  mysql_connect() in /var/enif/var/www/mojaenergija-test/proba.php on line 3

and when I run it from web everything works O.K. So the problem is somewhere in the configuration of PHP, it seems that mysql_connect() isn't available when running PHP as CGI binary.

But there's still one thing about eZ that worries me. eZ didn't display nor log any error message about this. Looking at the code it seems that problem is in the line that comes after mysql_connect():

$dbErrorText = mysql_error();

As far as I can figure, only mysql errors are gathered here, and this one (missing function) doesn't belong in mysql errors. Since mysql_connect() is called with @ in front, no errors were logged in the log file.

Is this wanted behavior or should I report this as a bug?

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth