24 Apr
2002
24 Apr
'02
10:18 p.m.
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.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
25 Apr
25 Apr
8:52 a.m.
----- Original Message -----
From: "Robin Johnson" <robbat2(a)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
10:42 a.m.
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 Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
11:26 a.m.
New subject: [Phpmyadmin-devel] old config file
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.
--
Marc Delisle
12:13 p.m.
New subject: [Phpmyadmin-devel] old config file
On Thu, 25 Apr 2002, Marc Delisle wrote:
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.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
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.
11:32 a.m.
----- Original Message -----
From: "Robin Johnson" <robbat2(a)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
9:06 a.m.
New subject: [Phpmyadmin-devel] converter
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(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Marc Delisle
10:45 a.m.
New subject: [Phpmyadmin-devel] converter
On Thu, 25 Apr 2002, Marc Delisle wrote:
I definetely agree with that.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
- 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.
8183
days inactive
8184
days old
7 comments
3 participants
participants (3)
-
Marc Delisle -
Rabus -
Robin Johnson