On Mon, 8 Apr 2002, Olivier M. wrote:

On Mon, Apr 08, 2002 at 11:57:00AM -0400, Marc Delisle wrote:

...

the development team would like to announce that the only official domain name for this project is http://phpmyadmin.net (which currently points to http://phpmyadmin.sourceforge.net).

yes, phpmyadmin.org and phpmyadmin.com are owned by people willing to make money by selling the domain names. They have *nothing* to do with the phpmyadmin devel team.

But I see from the whois records that you own it Oliver! ;-)

Either way, it's good to have it.

Thanks.

Just a note. My week of final exams is April 15th -> 19th, and then I am taking a week off relaxing, after which, I will be resuming a lot of work on phpMyAdmin.

Your database stored configuration should be ready in a month or so. It presently exists as a table by the name of 'config' in my database, and just works barely. I need to improve a lot of it still before it's ready for any other development work, and I want to make it more extensible.

For work on it, there is one thing I need to ask about. Would it be feasible to get the existing code written to use a pair of functions, pma_getvariable($name) and pma_setvariable($name,$data) whenever we are dealing with a configuration variable? That would be used to 'hide' the configuration system from the other developers, and reduce possible problems. I am using the PHP serialize/unserialize to store data in the database presently.

On Mon, 8 Apr 2002, Marc Delisle wrote:

I am not against using functions, but:

• what about the existing arrays in config.inc.php3?

That is the reason I was using serialize and unserialize to store the data. Those functions preserve arrays perfectly.

• implementing pma_getvariable() all over the code will be a lot of

work, so I suggest before starting this, to think also about a possible User Preferences module (db-stored also).

Could we decide on which of the options in the current configuration should be available to each user in their personal preferences?

Since it will just be the redefinition of some of the options from the main configuration, I propose doing it like this:

Read in the master 'config_master' table. Read in a client override table 'config_user' which is contains all the fields of 'config_master' plus one additional field for the username. The options for 'config_user' are set over the existing 'config_master' options.

Voila! You have user preferences. But we would need to put some security on that 'config_user' table, as there are probably some things that we do not want the user being able to change.

Also, looking at the security functions of this, as well as the speed considerations, using a database configuration system will REQUIRE a system that supports sessions, otherwise you risk poor performance (re-reading the configuration data on each page). By using sessions, it could be loaded once on login, and then re-loaded if the user changes preferences.

On Tue, 9 Apr 2002, Marc Delisle wrote:

For example, let's talk about $cfgShowBlob and assume that this can be a master and a user pref.

I guess you have put a "ShowBlob" field in the config_master table.

It would be more flexible not to have the actual cfg variable names as fields, but as data, so the config_master table would have 2 fields: the cfg variable name, and the cfg variable value (possibly serialized).

Yes, that is how I was considering doing it.

But there is one additional layer I had considered.

In the initial load of variables, we would do them in this order: 1. load variables from configuration file (base defaults and username/password for database access initially). 2. if configuration type is database, read in config_master 3. if configuration global allow user override, read in config_user on fields that have allow_override set in the config_master table. 4. in the config_user table, if allow_override is set, then the user can change that preference on their own. Otherwise the admin must set it for the user.

This is because we have to think about future PMA upgrades and avoid users having to add fields to config_master.

What do you think of that?

Yes. it would be good.

Maybe a third field to indicate if this can be overriden by the user (indicating a possible search in config_user).

Here are my two table structures that I have been playing around with:

CREATE TABLE config_master ( option VARCHAR(255) NOT NULL DEFAULT '', value TEXT, allow_override BOOL NOT NULL DEFAULT '0', PRIMARY KEY (option), KEY allow_override (allow_override) ) TYPE=MyISAM COMMENT='Master Configuration Options';

CREATE TABLE config_user ( user VARCHAR(255) NOT NULL DEFAULT '', option VARCHAR(255) NOT NULL DEFAULT '', value TEXT, allow_override BOOL NOT NULL DEFAULT '0', PRIMARY KEY (option), KEY allow_override (allow_override) ) TYPE=MyISAM COMMENT='User Configuration Options';

Looking at this, there are some questions I have, for people. should the 'value' column be BLOB type or TEXT type? How large will the data be? Could we shring it to TINYTEXT/BLOB or VARCHAR(255) ?

It is ok for me to require sessions for this, you are right about performance, and also because this will be an optional configuration mecanism.

Ok.

For security reasons, I also propose doing away with the 'only_db' option, as it is only a very poor substituate for proper user rights in MySQL.