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
Hi list!
>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.
Hum, you can use the config file from the 2.2.0 release till the
2.2.5 release and, if you can't with the 2.2.6 release, it's only
because of the "$cfgPmaabsoluteUri" directive that must be set
now.
Then we may only ensure compatibily with the config file from
the 2.2.6 release now.
>Possibly we just get around this by documenting the fact that
>is it not recommended they use their old configuration file
>between releases
That's already in the documentation ;)
I wonder what we will do if we add some directive in the next
releases? Won't we have to restore some pices of code to ensure
compatibility? In this case the file Alexander added to the CVS
is not so bad IMHO.
>On the download page, for version 2.2.5, we see that there
>were about 15000 downloads for files with .php3 extension, and
>this is probably a good indicator of the popularity of PHP3,
>even if .php extensions tend to be 5 times more downloaded.
I agree!
Kind regards,
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi,
Presently, we still write out code in such a way that it should work with
older releases of PHP and MySQL, however, I think we should conduct a
survey to see what versions are in wide use. If a lot of people are
tending to the newer versions of PHP/MySQL, then supporting them better is
for us, but if they still use old PHP/MySQL widely, then we need to
support them.
One of the features that this effects crucially is using SHOW GRANTS to
fix bug #474575.
Could one of the people with the main project administration rights please
give me access to set up a survey?
While you are at it, could I get administor access to the Trackers, so
that I could set up the category and group information data to make our
life using the trackers easier? I think this would be very important, so
that we can properly seperate the existing bugs under the 2.2 tree with
the bugs that are going to crop up under the 2.3 tree.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi List!
>Loic or Marc: could you please inform me what has been done
>with the CVS, as last I saw, there was some discussion about
>it.
I'm sorry but if won't have much free time till the end of
the week ie I might just be able to work on little things from
time to time :(
Please debate without me about whether to branch or not.
I'll do what you want.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi Robin & List!
>Rather than support the old file format, I will ask a friend
>that does a lot of regex replacement strings if there is a
>perl s/// command we can use to convert the existing config
>file they have to the new format.
Tht's not a so good idea: preg is an optionnal module for php3,
that's why we use only regexp in the whole code.
Moreover I'm pretty sure it's a hardest work for the server to
parse the file using regexp or preg than including a file with
some basic tests and affectsations.
Just my 2 cts. of Euro,
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi,
I would like to remove from config.inc.php3 the documentation about how to create the bookmarks
table, as we already have it in the doc.
--
Marc Delisle
----- Original Message -----
From: "Marc Delisle" <DelislMa(a)CollegeSherbrooke.qc.ca>
> Should we really support the old config file format?
common.lib.php3 would get really big if we did so...
I'd like to create a new file that would be included this way:
if (!isset($cfg)) require('config_import.lib.php3');
I could put all the old backwards compatibility code here.
imho we should support the old file format because the difference between
the old and the new format isn't that big.
Alexander
Greetings everybody,
Now that my finals are over, the first set of changes are going to be
underway for the DB-based configuration mechanisms.
The one major change that needs to put into the existing code revolves
around how we deal with the configuration variable names.
Presently in config.inc.php3 we have some code like this:
$cfgServers[$i]['relation'] = '';
$cfgServerDefault = 1;
etc.
For writing the configuration mechanism, I would like to move everything
to an array such as
$cfg['Servers'][$i]['relation'] = '';
$cfg['ServerDefault'] = 1;
Instead, and then I can implement the entire configuration mechanism
transparently inside a library function, that is called at startup to
handle anything that needs to be done.
Unfortunetly, there are ~760 instances of '$cfg', so this change is going
to take a while, and ideally we would want to have this change well
settled and in place to implement the configuration mechanism, as it
_WILL_ break things if it is only partially implemented.
Is somebody else willing to help me on this?
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
For those working on the configuration change
you may find this command helpful to track down places where you have not
yet fixed things:
egrep "\\\$cfg[[:alpha:]]" * -c
Loic or Marc: could you please inform me what has been done with the CVS,
as last I saw, there was some discussion about it.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639