Zeeshan Mughal a écrit :
Hi,
I have few things that I want to discuss.
I see some of the settings do not have their own user interface to edit them such as “PropertiesIconic”. I might have to change plans about implementing separate user interfaces for each settings, as they virtually do not exist for some of them. I am beginning to feel like this project is not just about having a feature to store settings permanently, but also providing users an interface to change those settings that they were not able to do so before because of not having access to config files on the server.
If you have a look at http://wiki.phpmyadmin.net/pma/SummerOfCode2009IdeasList#User_Preferences you'll see that this was exactly what was asked for this project:
"Some configuration parameters do not have an impact on security or performance; it would be interesting if each end-user of a shared PMA installation could change them on-the-fly and store these in pmadb."
I see all of the settings (currently under consideration) also have configuration options in ./libraries/config.default.php. Are these configs only there for initial installation purpose? What would happen if sysadmins change value for these options? Will these new settings override those stored in DB?
These configs will have to stay there )in the config.default.php + config.inc.php) because the userprefs feature might be not available.
IMO, as the parameters chosen to be part of userprefs should not have an impact on security or performance, the value set by each user will override the one set in the general config file.
Would it not be a decent idea to simply apply user settings to relative vars in ./libraries/config.default.php by extracting them from db? May be also have a mechanism to allow sysadmins to override DB stored settings?
Please give an example where this override would be needed.
I see there are several settings in ./libraries/config.default.php that can easily be imported to permanent settings user interface. Is there a limit on the number of settings that can have a place in the central admin interface due to performance, or some other issues?
This will have to be tested when we have an implementation prototype to test.
/Now, some coding questions:/
Following UPDATE query does not happen to perform any change to the table:
PMA_DBI_try_query("UPDATE pma_perm_usr_pref SET maxRows = 20 WHERE username = root")
Here, username is a column name and root is ... a column name?
And following SELECT query actually gives me a rather weird result:
PMA_DBI_try_query("SELECT maxRows FROM pma_perm_usr_pref WHERE username = root")
Same question. I think you forgot to quote the constant you are using.
results in: /Resource Id #61
/Of course, changeable values are not hard-coded in the actual script. :) Is there something wrong with the sql query?
For the later, I tried adding $link ( = PMA_DBI_select_db($cfg['Servers'][1]['pmadb']) ) parameter just to test if not having it was the problem. But, no luck.
Use $GLOBALS['cfg']['Server']['pmadb'].
Well, this brings me to my last question. For now, I am manually setting $i equal to 1. Is there a way to extract this server parameter from some automatically generated script?
Thank so much! Your help is much appreciated!