Ok, after one instance of $cfgServer that was missed by somebody, the CVS copy now appears to be back in a functional state.
I don't forsee any of my other changes breaking PMA like this.
Further more, did nobody else see my converter script to convert old instances of the configuration file to the new version?
It makes the libraries/config_import.lib.php3 file by Alex obsolete, as the user can convert the configuration file to the new format very easily. Do we want to use this to allow backwards compatibility, or do we require users to convert their configuration file with the Perl script?
Looking at functionality based on filenames, config_import.lib.php3 describes what my new functions will be doing. Importing configuration data from external sources. So if we are doing away with Alex's compatibilty code, then I will reuse that file for my import functions.
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
Further more, did nobody else see my converter script to convert old instances of the configuration file to the new version?
Well, the problem with your converter script is, that it only works with version 1.80 of config.inc.php3: If someone uses an older version, even the one from 2.2.6 (v1.79), some settings added in later versions are still missing afterwards since they are not being readded by your script...
Alexander
On Thu, 25 Apr 2002, Rabus wrote:
Well, the problem with your converter script is, that it only works with version 1.80 of config.inc.php3: If someone uses an older version, even the one from 2.2.6 (v1.79), some settings added in later versions are still missing afterwards since they are not being readded by your script...
Those variables that have been added over the growth of PHP are not just in this new release, but rather they have been added slowly over our development cycle. A person copying a configuration file say between 2.2.0 and 2.2.6 would face the same problem anyway, just because new variables have been added.
Possibly we just get around this by documenting the fact that is it not recommended they use their old configuration file between releases, but instead copy their settings over to the new file by hand?
Robin Johnson a écrit :
Possibly we just get around this by documenting the fact that is it not recommended they use their old configuration file between releases, but instead copy their settings over to the new file by hand?
This is already in Documentation.html. But possibly, sysadmins don't like that :) Anyway, with the new db-based system, maybe they will have less work to do.
On Thu, 25 Apr 2002, Marc Delisle wrote:
Possibly we just get around this by documenting the fact that is it not recommended they use their old configuration file between releases, but instead copy their settings over to the new file by hand?
This is already in Documentation.html. But possibly, sysadmins don't like that :) Anyway, with the new db-based system, maybe they will have less work to do.
I think there will definetly be less work in the end required. Combined with feature #479640, they will be able to do all of it, and allow their users some level of control at the same time.
For the time investment of doing the configuration file right once, they will have access to doing it via the DB nearly exclusively from there on. (Barring a few configuration settings that I am limiting to the config file for either security reasons, or the fact that they are needed to connect to the configuration database)
The security that I am implementing over the DB-based configuration will enable them to control the level of access that is presented to users by default.
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
Those variables that have been added over the growth of PHP are not just in this new release, but rather they have been added slowly over our development cycle. A person copying a configuration file say between 2.2.0 and 2.2.6 would face the same problem anyway, just because new variables have been added.
If someone used his phpMyAdmin 2.2.0 config file together with 2.2.6, I'd properbly work since common.lib.php3 adds the missing settings. If someone used his phpMyAdmin 2.2.0 config file together with 2.3.0-dev, I'd properbly work since config_import.lib.php3 adds the missing settings. If someone used his converted 2.2.0 config file together with 2.3.0-dev, I won't work because common.lib.php3 wouldn't call config_import.lib.php3! If someone used his phpMyAdmin 2.2.5 config file together with 2.2.6, I'd properbly work since common.lib.php3 adds the missing settings. If someone used his phpMyAdmin 2.2.5 config file together with 2.3.0-dev, I'd properbly work since config_import.lib.php3 adds the missing settings. If someone used his converted 2.2.5 config file together with 2.3.0-dev, I won't work because common.lib.php3 wouldn't call config_import.lib.php3!
confused enough? :o)
Alexander
Robin Johnson a écrit :
Ok, after one instance of $cfgServer that was missed by somebody, the CVS copy now appears to be back in a functional state.
I don't forsee any of my other changes breaking PMA like this.
Looks good here too.
Further more, did nobody else see my converter script to convert old instances of the configuration file to the new version?
Ok I just tested it, the converter looks ok here, but:
- We should document the fact that perl may be somewhere else than /usr/local/bin/perl
- Can it be done easily in PHP? I would prefer not adding PERL as a requirement for phpMyAdmin.
It makes the libraries/config_import.lib.php3 file by Alex obsolete, as the user can convert the configuration file to the new format very easily. Do we want to use this to allow backwards compatibility, or do we require users to convert their configuration file with the Perl script?
I prefer a converter than maintaining config_import_lib.php3 and the future variables.
Looking at functionality based on filenames, config_import.lib.php3 describes what my new functions will be doing. Importing configuration data from external sources. So if we are doing away with Alex's compatibilty code, then I will reuse that file for my import functions.
-- Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Thu, 25 Apr 2002, Marc Delisle wrote:
- We should document the fact that perl may be somewhere else than
/usr/local/bin/perl
Ok, good idea. This was the case on my system because I upgraded Perl.
- Can it be done easily in PHP? I would prefer not adding PERL as a
requirement for phpMyAdmin.
I am not certain about doing it in PHP without the use of the preg module, but I think it might be possible to convert it entirely into a shell script that uses sed/awk instead.
It makes the libraries/config_import.lib.php3 file by Alex obsolete, as the user can convert the configuration file to the new format very easily. Do we want to use this to allow backwards compatibility, or do we require users to convert their configuration file with the Perl script?
I prefer a converter than maintaining config_import_lib.php3 and the future variables.
I definetely agree with that.
-
Marc Delisle -
Rabus -
Robin Johnson