Hi all
current state when default values are written at two places (config.inc.php and libraries/config_import.lib.php) makes easy to make one of them different. And then we copy config file to config.default.php when releasing tarballs. So on each release configuration in placed on three places, in CVS "just" on two.
This could be IMO handled better way. I can currently see two possibilities, one quite easy to implement:
1. Manage just config.default.php in CVS. 2. User has to create config.inc.php. 3. Include config.inc.php. 4. Call fix up function, that will add missing values to configration based on config.default.php.
Function could look something like this (just to show how it could look like, I even haven't tested whether this code actually works):
function fixup_array(&$src, &$dst) { foreach($src as $key => $val) { if (!isset($dst($key)){ $dst[$key] = $val; } elseif (is_array($val)) { fixup_array($src[$key], $dst[$key]); } } }
function fixup() { include './config.default.php'; fixup_array($cfg, $GLOBALS['cfg']); }
Second possible solution would be do to this fixup only when that configuration options is actually needed. This would mean no direct reading of $cfg, but using some function instead, that will deal with default values. This definitely needs more modification to all code.
Comments?
Hi Michal and all,
indeed I would love to get rid of the $cfg['FileRevision'] mechanism.
I agree with your first idea. We could even do this: at run time, if config.inc.php is not there, try to create it from config.default.php and inform the user if it works or if it fails (could fail because of safe mode restrictions or just permission problems).
This way, we keep the current behavior that a default PMA installation works immediately without doing anything, permitting to connect to a default MySQL installation with root and no password (yeah!).
Note that at some places in the code we set some parts of $cfg dynamically based on the MySQL version, but this should not be a problem.
Let's not forget also config.inc.developer.php :)
See also https://sourceforge.net/tracker/index.php?func=detail&aid=1253493&gr...
Marc
Michal Čihař a écrit :
Hi all
current state when default values are written at two places (config.inc.php and libraries/config_import.lib.php) makes easy to make one of them different. And then we copy config file to config.default.php when releasing tarballs. So on each release configuration in placed on three places, in CVS "just" on two.
This could be IMO handled better way. I can currently see two possibilities, one quite easy to implement:
- Manage just config.default.php in CVS.
- User has to create config.inc.php.
- Include config.inc.php.
- Call fix up function, that will add missing values to configration
based on config.default.php.
Function could look something like this (just to show how it could look like, I even haven't tested whether this code actually works):
function fixup_array(&$src, &$dst) { foreach($src as $key => $val) { if (!isset($dst($key)){ $dst[$key] = $val; } elseif (is_array($val)) { fixup_array($src[$key], $dst[$key]); } } }
function fixup() { include './config.default.php'; fixup_array($cfg, $GLOBALS['cfg']); }
Second possible solution would be do to this fixup only when that configuration options is actually needed. This would mean no direct reading of $cfg, but using some function instead, that will deal with default values. This definitely needs more modification to all code.
Comments?
Hi
On Thu 8. 9. 2005 14:57, Marc Delisle wrote:
I agree with your first idea. We could even do this: at run time, if config.inc.php is not there, try to create it from config.default.php and inform the user if it works or if it fails (could fail because of safe mode restrictions or just permission problems).
Why to create it? We can just work when file is not existing. Creating file will anyway fail in most cases.
This way, we keep the current behavior that a default PMA installation works immediately without doing anything, permitting to connect to a default MySQL installation with root and no password (yeah!).
What is quite usual configuration on devel machines :-).
Note that at some places in the code we set some parts of $cfg dynamically based on the MySQL version, but this should not be a problem.
This is done anyway somewhere later.
Let's not forget also config.inc.developer.php :)
Yes: Let's not forget to remove also config.inc.developer.php :)
See also https://sourceforge.net/tracker/index.php?func=detail&aid=1253493&gr... up_id=23067&atid=377410
Looks interesting.
I'm currently (finally) working on new import system. I guess I could get to configuration stuff just after that. I have quite lot of time for coding right now as I'm ill at home ;-).
Michal Čihař a écrit :
Hi
On Thu 8. 9. 2005 14:57, Marc Delisle wrote:
I agree with your first idea. We could even do this: at run time, if config.inc.php is not there, try to create it from config.default.php and inform the user if it works or if it fails (could fail because of safe mode restrictions or just permission problems).
Why to create it? We can just work when file is not existing. Creating file will anyway fail in most cases.
Why create it? To avoid many support questions. Unless you tell me that PMA could work without a config.inc.php. Which might be an interesting idea: config.inc.php would really be config_local.inc.php?
This way, we keep the current behavior that a default PMA installation works immediately without doing anything, permitting to connect to a default MySQL installation with root and no password (yeah!).
What is quite usual configuration on devel machines :-).
And many productions machines unfortunately!
Note that at some places in the code we set some parts of $cfg dynamically based on the MySQL version, but this should not be a problem.
This is done anyway somewhere later.
Let's not forget also config.inc.developer.php :)
Yes: Let's not forget to remove also config.inc.developer.php :)
Ok, I see, because config.inc.php would not be in CVS anymore.
See also https://sourceforge.net/tracker/index.php?func=detail&aid=1253493&gr... up_id=23067&atid=377410
Looks interesting.
I'm currently (finally) working on new import system. I guess I could get to configuration stuff just after that. I have quite lot of time for coding right now as I'm ill at home ;-).
Take care!
Marc