Hi!
Is it a known bug of the 2.8.1 release that it doesn't load "config.inc.php" files?
I had two cases of the installation (one was done by a coworker of mine independantly from me) and we in the end had the same problem: Our config.inc.php file was not used. It was readable and all, but the config.default.php always seems to take precedence.
config.inc.php was put into the main s9y directory, the setup folder was deleted aftwards.
Thus we had to modify the config.default.php file, but I'm sure this is not intended? ;-)
Best regards, Garvin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
Is it a known bug of the 2.8.1 release that it doesn't load "config.inc.php" files?
I had two cases of the installation (one was done by a coworker of mine independantly from me) and we in the end had the same problem: Our config.inc.php file was not used. It was readable and all, but the config.default.php always seems to take precedence.
config.inc.php was put into the main s9y directory, the setup folder was deleted aftwards.
Thus we had to modify the config.default.php file, but I'm sure this is not intended? ;-)
is the config.inc.php write protected?
did you try to 'hardly' start a new session?
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
- -- Sebastian Mendel
www.sebastianmendel.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sebastian Mendel schrieb:
Garvin Hicking schrieb:
Hi!
Is it a known bug of the 2.8.1 release that it doesn't load "config.inc.php" files?
I had two cases of the installation (one was done by a coworker of mine independantly from me) and we in the end had the same problem: Our config.inc.php file was not used. It was readable and all, but the config.default.php always seems to take precedence.
config.inc.php was put into the main s9y directory, the setup folder was deleted aftwards.
Thus we had to modify the config.default.php file, but I'm sure this is not intended? ;-)
is the config.inc.php write protected?
did you try to 'hardly' start a new session?
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
'what' means 'which' ... ;-)
can you check into the config class? especially Config::__wakeup() which is responsible for checking this file and load it if it has changed.
- -- Sebastian Mendel
www.sebastianmendel.de
Hi!
is the config.inc.php write protected?
No, I even tried it with 0777.
did you try to 'hardly' start a new session?
Nope, I didn't think of that. I just re-tried the configuration, and then it does parse the proper configuration. So it seems it was previously not reloading an updated configuration? I set the auth_type to "http", and with that it still doesn't work. But with cookie/config type it does work now.
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
Regards, Garvin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
is the config.inc.php write protected?
No, I even tried it with 0777.
But it must be write protected! [Security]
did you try to 'hardly' start a new session?
Nope, I didn't think of that. I just re-tried the configuration, and then it does parse the proper configuration. So it seems it was previously not reloading an updated configuration? I set the auth_type to "http", and with that it still doesn't work. But with cookie/config type it does work now.
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
this call is in common.inc.php on line #2874
} elseif (version_compare(phpversion(), '5', 'lt')) { $_SESSION['PMA_Config']->__wakeup(); }
- -- Sebastian Mendel
www.sebastianmendel.de
Sebastian Mendel wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
is the config.inc.php write protected?
No, I even tried it with 0777.
But it must be write protected! [Security]
hehe, that's a responsible guy talking.
I had a problem with phpmyadmin for a brief moment when the config file was placed in the wrong folder. Is that the issue here?
did you try to 'hardly' start a new session?
Nope, I didn't think of that. I just re-tried the configuration, and then it does parse the proper configuration. So it seems it was previously not reloading an updated configuration? I set the auth_type to "http", and with that it still doesn't work. But with cookie/config type it does work now.
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
this call is in common.inc.php on line #2874
} elseif (version_compare(phpversion(), '5', 'lt')) { $_SESSION['PMA_Config']->__wakeup(); }
Sebastian Mendel
www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32)
iD8DBQFEjWRHX/0lClpZDr4RAgJ6AKC0lZVAYkogFrv4R39GMe53eaXeQQCfQnCE 8W98WopuP6PpWOx2QzHKbK8= =Bp2a -----END PGP SIGNATURE-----
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Garvin Hicking a écrit :
Hi!
is the config.inc.php write protected?
No, I even tried it with 0777.
did you try to 'hardly' start a new session?
Nope, I didn't think of that. I just re-tried the configuration, and then it does parse the proper configuration. So it seems it was previously not reloading an updated configuration? I set the auth_type to "http", and with that it still doesn't work. But with cookie/config type it does work now.
can you check into the config class? especially Config::__wakeup() what is responsible for checking this file and load it if it has changed.
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
I just tried 2.8.1 on a PHP 4.4.0 server and __wakeup is called.
Marc
Regards, Garvin
Hi!
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
I just tried 2.8.1 on a PHP 4.4.0 server and __wakeup is called.
I'll try to run some tests with the one server that is left with the bug - but it can be narrowed down to this: Init the session with a missing config.inc.php file to force the default parsing of the config file. Then I change the config.inc.php file with valid info. Using IE6 (my other browser) I can then login to PMA. Using the browser that I started with, it still tries to parse the default config file.
I'm not yet sure what is going on there, so I'll need some time to do some testing. I can only access the server from work, so I'll need to try it tomorrow.
Regards, Garvin
Garvin Hicking a écrit :
Hi!
That server is running PHP4, so __wakup will not be called. Is this intentional to depend on PHP4, or am I missing a PHP4 BC method call somewhere?
I just tried 2.8.1 on a PHP 4.4.0 server and __wakeup is called.
I'll try to run some tests with the one server that is left with the bug - but it can be narrowed down to this: Init the session with a missing config.inc.php file to force the default parsing of the config file. Then I change the config.inc.php file with valid info. Using IE6 (my other browser) I can then login to PMA. Using the browser that I started with, it still tries to parse the default config file.
Same situation as this?
https://sourceforge.net/tracker/index.php?func=detail&aid=1471501&gr...
I'm not yet sure what is going on there, so I'll need some time to do some testing. I can only access the server from work, so I'll need to try it tomorrow.
Regards, Garvin