[Phpmyadmin-devel] RFE #1123

[Isaac Bennetch]

Hi, I quite agree with what Marc said, but I have a few thoughts in-line
below:

On 8/5/14, 5:16 PM, Marc Delisle wrote:
> Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
>> Hi,
>>
>> I was starting to work on RFE #1123
>> <https://sourceforge.net/p/phpmyadmin/feature-requests/1123/> (Zeroconf
>> PMA tables support).
>>
>> Is it something like enabling/disabling the PMA configuration storage
>> feature through UI with default table names?
>>
>> Also, automatically create these tables when user has enabled this
>> feature through UI?
> 
> Hi Ashutosh,
> 
> I have read again the RFE and the comments in the ticket; then I read
> the details of your proposal on google-melange.com.
> 
> I don't have all the answers but can give you some pointers; others can
> give ideas too or contradict mine :)
> 
> * The solution has to work for a single-user installation and also for a
> multi-user installation
> 
> * Priority should go to use the values from config.inc.php (the control
> user, pmadb and all pmadb tables) if present. This is mainly for
> backward compatibility and also because I suspect it's the only way to
> support a multi-user installation
> 
> * In case there is no such configuration, the logic could check the
> presence of the default database name and table names, as suggested in
> examples/create_tables.sql
> 
> * I'm not sure on which panel is the best place to do this verification,
> but it could be at the same places where the warnings about the
> configuration storage are currently done (home page and each database >
> Operations page

This makes the most sense to me as well.

> * If this default database name "phpmyadmin" does not exist, the logic
> could look for the default table names in the current database (this is
> in case the user has access to only one database)
> 
> * If the default db and/or default table names are not found, the logic
> could pop a dialog, offering to create these in the current db and
> asking for confirmation; I hope it's possible to directly read
> examples/create_tables.sql for this, in order to avoid discrepancies
> between the logic and changes in create_tables.sql
>
> * Something will have to be done with the logic that gives a warning
> about the configuration storage; it would probably lose its purpose
> 
> * Maybe we'll need a new directive in config.inc.php, so that the
> installer can decide that the zero conf is active or not (would be
> active by default)

This is probably best.

> * I am not in favor of designing a UI to set up the configuration
> storage, as this already exists in /setup (with the goal of producing a
> config.inc.php)

I agree.

> * I am not in favor of programmatically creating a .php file in the
> installation directory or doing any modification in config.inc.php

I also agree with this.