Hi,
I plan to release 2.3.0-rc1 tomorrow, then we only merge: - translation updates - light patches - light bug fixes.
Any show stopper you can think of?
Marc
On Mon, 17 Jun 2002, Marc Delisle wrote:
I plan to release 2.3.0-rc1 tomorrow, then we only merge:
- translation updates
- light patches
- light bug fixes.
Any show stopper you can think of?
These are two bugs I think we need to make sure have been dealt with: Bugs: #568805 #568174
I've merged some of the translations already (Italian and Finnish).
Robin Johnson wrote:
On Mon, 17 Jun 2002, Marc Delisle wrote:
I plan to release 2.3.0-rc1 tomorrow, then we only merge:
- translation updates
- light patches
- light bug fixes.
Any show stopper you can think of?
These are two bugs I think we need to make sure have been dealt with: Bugs: #568805
This one is about Function redeclare, in PHP 4.2.1, for version 2.2.6. Does someone (like Olivier) get this error for version 2.3.0-dev?
#568174
I don't think this one is a show stopper for 2.3.0-RC1.
Marc
Hi Marc & everybody,
I'm still alive :) Just having a very heavy university year, and no time currently to code on PMA till summer (exams and 'Semesterarbeit'): but I'm still following the lists, cvs, and the great work!
On Mon, Jun 17, 2002 at 04:52:37PM -0400, Marc Delisle wrote:
I plan to release 2.3.0-rc1 tomorrow, then we only merge:
- translation updates
- light patches
- light bug fixes.
Any show stopper you can think of?
a few things:
* many links on the main.php3 page return errors on my linux php 4.2.1/mysql 3.23.44 system: show runtime infos, show variables, change password (-> php parse error!!!), show processlist: -> You have an error in your SQL syntax near '' at line 1 (tested with opera and netscape)
* Another error when I click on the "Operation" menu (table display): -> You have an error in your SQL syntax near '' at line 1
* I don't really like the current look of the "Menus", now that they are much more important than before: ( [ SQL | Structure | Export | Search | Query by Example ] ), etc.
what about displaying them as Tabs (like under http://www.altavista.com/ or http://images.google.ch/images?q=phpmyadmin&hl=de&btnG=Google-Suche ) ?
* Maybe that displaying a "detailled" menu (same as the list of links, but in a table, with operation description) on the tbl_properties.php3 and db_details.php3 pages would be a good idea? (before the big SQL text field) : would be more userfriendly...
* Other thing (requested by friends testing 2.3): would there be a way to optionnaly have all options back to the db_default/tbl_propr page ? (kind of "expert" mode, with flag in the config file) ? For example a "simple" include(tbl_properties_*.php3) in tbl_properties.php3 and the same in db_details.php3. Would be good for lazy (less mouse clicks...) and power users.
Voila, that was all for tonight, back to school work... :/ Cheers, Olivier
Olivier M. wrote:
- many links on the main.php3 page return errors on my
linux php 4.2.1/mysql 3.23.44 system: show runtime infos, show variables, change password (-> php parse error!!!), show processlist: -> You have an error in your SQL syntax near '' at line 1 (tested with opera and netscape)
The parse error is fixed. I cannot reproduce any of the other errors in Apache 1.3/PHP 4.1.2.
Olivier, are you running your PHP 4.2.1 with Apache 2? Apache 1.3? other server?
- Another error when I click on the "Operation" menu
(table display): -> You have an error in your SQL syntax near '' at line 1
This does not happen here.
- I don't really like the current look of the "Menus", now that
they are much more important than before: ( [ SQL | Structure | Export | Search | Query by Example ] ), etc.
what about displaying them as Tabs (like under http://www.altavista.com/ or http://images.google.ch/images?q=phpmyadmin&hl=de&btnG=Google-Suche ) ?
This is not a show stopper, IMHO. We will be able to improve on next versions, but this one is already an improvement.
- Maybe that displaying a "detailled" menu (same as the list of links,
but in a table, with operation description) on the tbl_properties.php3 and db_details.php3 pages would be a good idea? (before the big SQL text field) : would be more userfriendly...
- Other thing (requested by friends testing 2.3): would there be a way to
optionnaly have all options back to the db_default/tbl_propr page ? (kind of "expert" mode, with flag in the config file) ? For example a "simple" include(tbl_properties_*.php3) in tbl_properties.php3 and the same in db_details.php3. Would be good for lazy (less mouse clicks...) and power users.
Not show stoppers either, Olivier. But I don't understand exactly your point. All options? Do you mean all sub-pages? And go back where? to the new "SQL" sub-pages?
Marc
Marc Delisle wrote:
Olivier M. wrote:
- many links on the main.php3 page return errors on my
linux php 4.2.1/mysql 3.23.44 system: show runtime infos, show variables, change password (-> php parse error!!!), show processlist: -> You have an error in your SQL syntax near '' at line 1 (tested with opera and netscape)
Olivier, as suggested by Luc and retested by me, this happens if you forget to set your $cfg['Servers'][$i]['pmadb'].
Marc
Marc Delisle wrote:
Marc Delisle wrote:
Olivier M. wrote:
- many links on the main.php3 page return errors on my
linux php 4.2.1/mysql 3.23.44 system: show runtime infos, show variables, change password (-> php parse error!!!), show processlist: -> You have an error in your SQL syntax near '' at line 1 (tested with opera and netscape)
Olivier, as suggested by Luc and retested by me, this happens if you forget to set your $cfg['Servers'][$i]['pmadb'].
Well ok, a user can let this field blank, and the error should not happen :) another bug to kill...
Marc
Olivier M. wrote:
- many links on the main.php3 page return errors on my
linux php 4.2.1/mysql 3.23.44 system: show runtime infos, show variables, change password (-> php parse error!!!), show processlist: -> You have an error in your SQL syntax near '' at line 1 (tested with opera and netscape)
Olivier, as suggested by Luc and retested by me, this happens if you forget to set your $cfg['Servers'][$i]['pmadb'].
Well ok, a user can let this field blank, and the error should not happen :) another bug to kill...
Should be fixed now. Marc
On Mon, Jun 17, 2002 at 10:35:32PM -0400, Marc Delisle wrote:
Olivier, as suggested by Luc and retested by me, this happens if you forget to set your $cfg['Servers'][$i]['pmadb'].
Well ok, a user can let this field blank, and the error should not happen :) another bug to kill...
Should be fixed now. Marc
I confirm, looks much better now :) Olivier
On Tue, Jun 18, 2002 at 08:12:02AM +0200, Olivier M. wrote:
On Mon, Jun 17, 2002 at 10:35:32PM -0400, Marc Delisle wrote:
Should be fixed now. Marc
I confirm, looks much better now :) Olivier
another little thing:
db_stats.php3 (same setup: php 4.2.1, apache 1.3) -> some ugly warnings like:
Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 234 Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 256
will/may have a look on it after my exams of today... :) regards, Olivier
Olivier M. wrote:
db_stats.php3 (same setup: php 4.2.1, apache 1.3) -> some ugly warnings like:
Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 234 Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 256
will/may have a look on it after my exams of today... :) regards, Olivier
Robin, can you reproduce this one?
On Tue, 18 Jun 2002, Marc Delisle wrote:
db_stats.php3 (same setup: php 4.2.1, apache 1.3) -> some ugly warnings like:
Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 234 Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/admin/www/mysql2/db_stats.php3 on line 256
Robin, can you reproduce this one?
No, my test environment doesn't produce this error.
Hi Marc and list,
It probably does not set 'pmadb' in spite of setting 'relation','table_info','table_coords' and 'pdf_pages'.
Marc Delisle wrote:
Olivier M. wrote: :
- Another error when I click on the "Operation" menu
(table display): -> You have an error in your SQL syntax near '' at line 1
This does not happen here.
Hi,
Please also release 2.2.7 RC1. I'll make the branch ready for release tonight.
2.2.7 will be a good alternative for all who want a stable phpMyAdmin and don't need the new features of 2.3.0.
Before you do the release, don't forget to remove ChangeLog_till_2.2.6.gz from CVS and put it on phpmyadmin.net.
Regards,
Alexander
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Monday, June 17, 2002 10:52 PM Subject: [Phpmyadmin-devel] 2.3.0-rc1 tomorrow?
Hi,
I plan to release 2.3.0-rc1 tomorrow, then we only merge:
- translation updates
- light patches
- light bug fixes.
Any show stopper you can think of?
Marc
Hi again,
We should imho first fix the bugs Robin has just found before we release RC 1. Furthermore, the backwards compatibility code for old config files does not seem to work correctly, I'll work on a better one tomorrow (CET). Let's wait a one ore two more days with RC 1.
Alexander
On Wed, 19 Jun 2002, Rabus wrote:
We should imho first fix the bugs Robin has just found before we release RC 1.
Ok.
Furthermore, the backwards compatibility code for old config files does not seem to work correctly, I'll work on a better one tomorrow (CET). Let's wait a one ore two more days with RC 1.
What about the conversion script I wrote to convert the old format to the new format ?
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
Furthermore, the backwards compatibility code for old config files does
not
seem to work correctly, I'll work on a better one tomorrow (CET). Let's wait a one ore two more days with RC 1.
What about the conversion script I wrote to convert the old format to the new format ?
Well, the funny thing is: If someone used your script, he'd get more problems than hed had before :o) The import code is only executed if the $cfg array doesn't exist. So currently you can only convert v1.80 without problems with your script. But I'll work on that, too.
Alexander
On Wed, 19 Jun 2002, Rabus wrote:
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
Furthermore, the backwards compatibility code for old config files does
not
seem to work correctly, I'll work on a better one tomorrow (CET). Let's wait a one ore two more days with RC 1.
What about the conversion script I wrote to convert the old format to the new format ?
Well, the funny thing is: If someone used your script, he'd get more problems than hed had before :o) The import code is only executed if the $cfg array doesn't exist. So currently you can only convert v1.80 without problems with your script. But I'll work on that, too.
Actually, I tested it out, and found that the raw v1.80 configuration file causes MORE problems if it isn't converted using the script.
At least when you convert it with the script the errors it gives you are more reasonable.
If you don't convert it, and let the import code try to do it instead, you get this horrible purple page that keeps complaining about $cfg['PmaAbsoluteUri'].
On my mode, it actually shows this set of warnings: Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 16
Notice: Undefined index: AllowDeny in /home/robbat2/cvs/phpMyAdmin/libraries/common.lib.php3 on line 586
Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 115
Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 51
Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 115
Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 115
Notice: Undefined index: AllowAnywhereRecoding in /home/robbat2/cvs/phpMyAdmin/libraries/charset_conversion.lib.php3 on line 51
I've hunted down all of these fragments for now and put a isset() statement in front of them.
PMA actually now WORKS better with an old configuration file that has just been passed thru the convertor. Sure, there are errors sprouting everywhere because of unset configuration variables, but they aren't critical errors from what I can see.
If somebody spared 30 minutes, you could probably hunt down all of the other Notice errors like this.
I'll sit down and do it tommorow morning my time, as I think a little bit of coding the main system properly is better than trying to always update the config_import backwards compatibility stuff.
On Wed, Jun 19, 2002 at 01:22:52AM -0700, Robin Johnson wrote:
If you don't convert it, and let the import code try to do it instead, you get this horrible purple page that keeps complaining about $cfg['PmaAbsoluteUri'].
about this thing, what about letting PMA still work, even with en empty PmaAbsoluteUri (getting the infos from HTTP vars), and displaying a small warning somewhere "please setup the variable"... ? It was the case before and worked fine, but for a reason I don't remember the feature has been removed.
Reason: I have a PMA on a "*.domain.ch" domain with some mappings, with and without ssl, and I'd like to keep only one copy of PMA arround, not 4 like now...
What do you think ? :) Olivier
On Wed, 19 Jun 2002, Olivier M. wrote:
about this thing, what about letting PMA still work, even with en empty PmaAbsoluteUri (getting the infos from HTTP vars), and displaying a small warning somewhere "please setup the variable"... ? It was the case before and worked fine, but for a reason I don't remember the feature has been removed.
I'd support this, and I'd say we should do it in this order: if PmaAbsoluteUri is empty, then try one of the automatic methods for it as listed in the Documentation.html, and display the warning as Oliver said. They can then copy the automatic examples from the Documentation.html if those work for them, and the warning will go away.
Reason: I have a PMA on a "*.domain.ch" domain with some mappings, with and without ssl, and I'd like to keep only one copy of PMA arround, not 4 like now...
Have you tried the automatic mappings as suggested in the Documentation.html? They work fine under all of my Apache systems.
Hi Robin & list,
On Wed, Jun 19, 2002 at 01:58:49AM -0700, Robin Johnson wrote:
about this thing, what about letting PMA still work, even with en empty PmaAbsoluteUri (getting the infos from HTTP vars), and displaying a small warning somewhere "please setup the variable"... ?
I'd support this, and I'd say we should do it in this order: if PmaAbsoluteUri is empty, then try one of the automatic methods for it as listed in the Documentation.html, and display the warning as Oliver said. They can then copy the automatic examples from the Documentation.html if those work for them, and the warning will go away.
exactely!
Reason: I have a PMA on a "*.domain.ch" domain with some mappings, with and without ssl, and I'd like to keep only one copy of PMA arround, not 4 like now...
Have you tried the automatic mappings as suggested in the Documentation.html? They work fine under all of my Apache systems.
yes, this was what I was thinking about. So the only thing to do would be to set the variable to one of these automatic mappings per default if PmaAbsoluteUri == ''.
Olivier, currently fighting with Docboox/xml (btw, docbook based doc would be cool for PMA too :) : Documentation.html is getting big....)
Rabus wrote:
Hi again,
We should imho first fix the bugs Robin has just found before we release RC
Alexander,
570691 is fixed
For 570632 and 570680 I proposed to deactivate the code since those are new features and can be delayed. And Mike could work on them after he is back in town.
For 570698, I don't think it's a show stopper for a RC1.
In short, I still would like to release 2.3.0-rc1 today :)
On Tue, 18 Jun 2002, Marc Delisle wrote:
570691 is fixed
Confirmed.
For 570632 and 570680 I proposed to deactivate the code since those are new features and can be delayed. And Mike could work on them after he is back in town.
See my e-mail to the mailing list and Bug #570898. Definetly deactive the entire SQL formatter. The entire PMA_format_sql() needs to be re-written.
For 570698, I don't think it's a show stopper for a RC1.
Agreed. We can fix it for RC2.
In short, I still would like to release 2.3.0-rc1 today :)
Fine by me. Make sure to deactivate the entire PMA_format_sql(); The easiest way would be to make an overriding function that just passing the string straight thru, and rename the existing PMA_format_sql().
-
luc -
Marc Delisle -
Marc Delisle
-
Olivier M. -
Rabus -
Robin Johnson