Hi,
how about add an 'Registration' in main.php which leads to local registration form
this form could collect, of course after explaining and asking for permission:
- number of servers/databases/tables handled with this installation - currently installed versions of PHP, PMA, MySQL - used extension mysql, mysqli - changed configuration (different from default) - used theme - registration information (email, name, company, ... ) - hash of installation path (as unique id for installation) - hash of server connection string (as unique id for servers) - a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default - send security alerts on specific versions - statistics on used versions - and much more ...
Sebastian Mendel a écrit :
Hi,
how about add an 'Registration' in main.php which leads to local registration form
this form could collect, of course after explaining and asking for permission:
- number of servers/databases/tables handled with this installation
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default
- send security alerts on specific versions
- statistics on used versions
- and much more ...
Hi Sebastian, I guess that if we implement this, the registration form should be displayed only to a super-user.
But I'm not sure I like the idea, for those reasons:
- I would not like to have to handle all this data - I think that users would have a negative perception, seeing "registration" - if we use the project database for this, we would have to remove our demo (believe me, for security reasons) - the whole user settings system should migrate to db-based user preferences, and/or an installation GUI - about the alerts, we already send them, with indications on the affected versions
I think that download stats about themes indicate correctly the popularity. Besides, each user of a multi-user installation can choose his theme, so you want each user to participate in the registration?
Marc
Marc Delisle wrote:
Sebastian Mendel a écrit :
Hi,
how about add an 'Registration' in main.php which leads to local registration form
this form could collect, of course after explaining and asking for permission:
- number of servers/databases/tables handled with this installation
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default
- send security alerts on specific versions
- statistics on used versions
- and much more ...
Hi Sebastian, I guess that if we implement this, the registration form should be displayed only to a super-user.
yes
But I'm not sure I like the idea, for those reasons:
- I would not like to have to handle all this data
- I think that users would have a negative perception, seeing
"registration"
than let us call it "help for improvement" ;-)
- if we use the project database for this, we would have to remove our
demo (believe me, for security reasons)
- the whole user settings system should migrate to db-based user
preferences, and/or an installation GUI
- about the alerts, we already send them, with indications on the
affected versions
i mean to registered users email addresses, who are registered with the affected version
I think that download stats about themes indicate correctly the popularity. Besides, each user of a multi-user installation can choose his theme, so you want each user to participate in the registration?
no, not really - only a 'installation'-registration
I merged two threads :-)
On Thu 13. 10. 2005 17:16, Sebastian Mendel wrote:
Marc Delisle wrote:
I think that download stats about themes indicate correctly the popularity. Besides, each user of a multi-user installation can choose his theme, so you want each user to participate in the registration?
no, not really - only a 'installation'-registration
Well I'd forget this until we have setup script. You can then easily add this as part of installation, however right now it will be more annoying:
On Thu 13. 10. 2005 17:14, Sebastian Mendel wrote:
Michal Čihař wrote:
On Thu 13. 10. 2005 12:24, Sebastian Mendel wrote:
this can be stored local, or at least a hash over all, to recognize changes and update registration
stored where? in pmadb? this is currently only place where you can save anything, but it is not enabled on most installations
or just in a file (just test for write privilelgs, if not no error)
In most cases you can not write to file, so you will silently fail and still offer registration?
- send security alerts on specific versions
You can't handle this as vendors often backport security patches, so you don't know whether version user has installed is really vulnerable.
alerts only on first time to 'registered' users with this version to given email adress - when the security alert comes the first the vendors will mostly not have applied any patch adressing this issue
Wrong, if you install some distribution, you will get patched version, but it is usually not current one (especially "enterprise" distribution release cycles are very long, so you might have 3 years old patched version). This will only force vendors to disable such checks, you can see how similar feature in Firefox is mostly disabled in distributions.
Hi
On Thu 13. 10. 2005 12:24, Sebastian Mendel wrote:
how about add an 'Registration' in main.php which leads to local registration form
People don't like registrations, I'm not sure whether effort invested into this will return in any positive value.
this form could collect, of course after explaining and asking for permission:
- number of servers/databases/tables handled with this installation
number of servers is configuration, however rest are dynamic values changing quite a lot over time
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
this is per user settings, doesn't make much sense to collect it
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize changes and update registration
stored where? in pmadb? this is currently only place where you can save anything, but it is not enabled on most installations
and of course in the phpMyAdmin project database
This would mean dropping demo ... hmm I'd rather host this database than demo, so maybe it could be solved.
so we can
- make most used settings to default
Yes, this would be helpful.
- send security alerts on specific versions
You can't handle this as vendors often backport security patches, so you don't know whether version user has installed is really vulnerable.
- statistics on used versions
- and much more ...
Michal Čihař wrote:
Hi
On Thu 13. 10. 2005 12:24, Sebastian Mendel wrote:
how about add an 'Registration' in main.php which leads to local registration form
People don't like registrations, I'm not sure whether effort invested into this will return in any positive value.
this form could collect, of course after explaining and asking for permission:
- number of servers/databases/tables handled with this installation
number of servers is configuration, however rest are dynamic values changing quite a lot over time
you are right, ...
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
this is per user settings, doesn't make much sense to collect it
oh, of course per user settings not ...
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize changes and update registration
stored where? in pmadb? this is currently only place where you can save anything, but it is not enabled on most installations
or just in a file (just test for write privilelgs, if not no error)
- send security alerts on specific versions
You can't handle this as vendors often backport security patches, so you don't know whether version user has installed is really vulnerable.
alerts only on first time to 'registered' users with this version to given email adress - when the security alert comes the first the vendors will mostly not have applied any patch adressing this issue
I recently edited a table for a column change on an enum.
The column is not null with a default set and '' is not a member of the enum.
This is the output from PHPMyadmin where I changed 'Artist' to 'Music Artist'
Table contact_types has been altered.
SQL query:
ALTER TABLE `contact_types` CHANGE `contact_type` `contact_type` ENUM( 'Actor', 'Actress', 'Music Artist', 'Band', 'Company', 'Unknown' ) NOT NULL DEFAULT 'Unknown'
[ Edit ] [ Create PHP Code ]
This resulted in all the existing rows that had the value 'Artist' changing to ''. First, I guess I expected that it would change those rows to Music Artist but that's my own fault. Second, the fact that it didn't utilize my default definition ended up "better" than if it had change it to 'Unknown'
However, running this from the command line results in the following output:
Query OK, 1578 rows affected, 21 warnings (0.06 sec)
Records: 1578 Duplicates: 0 Warnings: 21
mysql> show warnings;
+---------+------+------------------------------------------------------+
| Level | Code | Message |
+---------+------+------------------------------------------------------+
| Warning | 1265 | Data truncated for column 'contact_type' at row 9 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 11 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 39 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 529 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1533 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1534 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1535 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1536 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1537 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1538 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1539 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1540 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1541 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1542 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1547 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1558 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1568 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1569 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1574 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1575 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1576 |
+---------+------+------------------------------------------------------+
21 rows in set (0.00 sec)
I believe that the existence of warnings is important and warrants a change in PHPMyAdmin.
Thoughts?
KAM
Hi
On Thu 13. 10. 2005 17:41, Kevin A. McGrail wrote:
I recently edited a table for a column change on an enum.
The column is not null with a default set and '' is not a member of the enum.
This is the output from PHPMyadmin where I changed 'Artist' to 'Music Artist'
Table contact_types has been altered.
SQL query:
ALTER TABLE `contact_types` CHANGE `contact_type` `contact_type` ENUM( 'Actor', 'Actress', 'Music Artist', 'Band', 'Company', 'Unknown' ) NOT NULL DEFAULT 'Unknown'
[ Edit ] [ Create PHP Code ]
This resulted in all the existing rows that had the value 'Artist' changing to ''. First, I guess I expected that it would change those rows to Music Artist but that's my own fault. Second, the fact that it didn't utilize my default definition ended up "better" than if it had change it to 'Unknown'
However, running this from the command line results in the following output:
Query OK, 1578 rows affected, 21 warnings (0.06 sec)
Records: 1578 Duplicates: 0 Warnings: 21
mysql> show warnings;
+---------+------+--------------------------------------------------- ---+
| Level | Code | Message |
+---------+------+--------------------------------------------------- ---+
| Warning | 1265 | Data truncated for column 'contact_type' at row 9 | | | | Warning | 1265 | Data truncated for column 'contact_type' at row 11 | | | | Warning | 1265 | Data truncated for column 'contact_type' at row 39 | | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 529 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1533 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1534 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1535 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1536 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1537 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1538 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1539 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1540 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1541 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1542 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1547 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1558 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1568 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1569 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1574 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1575 | | | Warning | 1265 | Data truncated for column 'contact_type' at row | 1576 |
+---------+------+--------------------------------------------------- ---+
21 rows in set (0.00 sec)
I believe that the existence of warnings is important and warrants a change in PHPMyAdmin.
Thoughts?
File feature request for handling MySQL warnings.
-
Kevin A. McGrail -
Marc Delisle -
Michal Čihař -
Sebastian Mendel