Developers

developers@phpmyadmin.net

7002 discussions

RE: [Phpmyadmin-devel] tests on cvs version
by Benjamin Gandon 07 Aug '01

07 Aug '01

> > - in Documentation.html: "Obviously, you're free to use whatever > > coding style you want." Thas was true by the time Tobias started > > coding. Now, I would put "Please follow the PEAR coding > standards as > > close as possible when indenting and formating your code." > > Good idea! Are you modifying the file? I'll do it tonight if it's not yet done...

1 0

RE: [Phpmyadmin-devel] tests on cvs version
by Benjamin Gandon 07 Aug '01

07 Aug '01

> > - PLEASE TELL IT WHEN YOU CHANG ALL END OF LINES! It's really a hell > > dealing with confilcts all over each file! It's really > not a common > > thing, so you *MUST* warn everybody before doing it! I'm sorry I got angry a bit fast. Actually dealing with such simple conflicts is not such a big thing... > Do you mean when I used remove_control_m.sh? Yep. In fact it is kind a coordination problem. Coordination is needed as mentionnend in "what is not CVS" in Molli's CVS manual. I thought you would warn the mailing list before doing such an update. I think freezing CVS or something like that is required before updates that deal with such an amount of lines or else every body who has made changes in the meanwhile can't commit them because they conflict. An entry in ChangeLog is not sufficient because developers can't see it early enough. When they try to commit and have conficts, it's too late.

1 0

RE: [Phpmyadmin-devel] split_sql_file produces sometimes wrong pieces
by Benjamin Gandon 07 Aug '01

07 Aug '01

> Yes I added that line and it was to fix an error involving > round brackets. So that really was a quick hack. I think you should have mentionned that in the code. > The problem is that > readdump.php is > set-up to try and handle too many different types of queries. Well, I still think it's suitable like that. Indeed dealing with an uploaded dump and a dump that would have been pasted in the SQL query textarea is really the same and I think it really has to be treated the same way. > > Actually, there is another big bug in this function that is here > > since the very begining of phpMyAdmin. Try that kind of manual SQL > > insert and it won't work: > > insert into table values ('\\');insert into table values ('\\'); > > This problem can be fixed with some quite complex code, but > is will make the > code so slow it will be absolutely useless for database/table > restoration. Well, it's already fixed in CVS. Go and have a look at the code. Honestly, I don't think it's as complex as that. If you find some bug, please tell me. > The only solution I can think of is to split the database > restore code from the normal queries text box > So the choice is to either live with the current small bugs > or rethink and > redesign the whole section. Now, the bug should be away. Could you test? > I have included a small test table containing lots of > different symbols, > this was the test data used to verify the current system. Could you test the current CVS version with your test table, to see if my modification is ok? That would really help. Benjamin

1 0

RE: [Phpmyadmin-devel] removing remarks is useless
by Benjamin Gandon 07 Aug '01

07 Aug '01

> > - lib.inc.php3: the function remove_remarks() is bugged because > > if a string contains a '#' in a string, it is considered as a > > comment. As stated in bug #444279. > > > > I already said that comments need not being stripped off queries. > > Mysql works just fine if you give it all the comments. No need > > removing them (as is was in my 2.1.0.1 version). > > do you know if there are old MySQL versions that would not like > comments? Well... I don't know. I just think that parsing scheme sould have been designed to accept comments in queries for a while or else every client would have to include a query parser to remove comments, which is not really acceptable. One parser is enough. In version 2.1.0 from Tobias, removal of comments was all but very smart : $sql = ereg_replace("#[^\n]*\n", "", $sql); In fact I think Tobias had just thought it would speed up the SQL query when adding this small feature. ChangeLog doesn't say anything about a bug involving comments in queries... Benjamin PS: if you want to see original 2.1.0 sources, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpnextadmin/phpMyAdmin/ :)))

1 0

RE: [Phpmyadmin-devel] tests on cvs version
by Benjamin Gandon 07 Aug '01

07 Aug '01

> Try first this: > ssh gandon(a)cvs.phpmyadmin.sourceforge.net > > and this will create your homedir there. Thanks. I finally found that by chance. I had not seen anything about it in sourceforge doc. I'm surprised it's not written in red and bold face somewhere I could have seen it very well...

1 0

[Phpmyadmin-devel] german umlauts not work
by Steve Alberty 07 Aug '01

07 Aug '01

Hi, the new version have many problems with german umlauts. The normal output works, but the echo over mysql_die for example, convert the special characters like ü to &uuml; also the output over javascripts is wrong. a temporary solution is a back-convert in the affected string, ü to ü should i do this? Regards, Steve

5 12

[Phpmyadmin-devel] putting a @, or if (function_exists)) ?
by Marc Delisle 07 Aug '01

07 Aug '01

Hi, in phpwizard.net's forum: --------- Hiyas, Just a bug report that phpmyadmin 2.2.0 doesn't work with php4.0b3 .. as far as i can figure, this is because the php function 'extension_loaded' (used in lib.inc.php) isn't supported below PHP 3.0.10 and under PHP 4.0b4 Cheers James QH ----------- Should we check if the function extension_loaded exists before calling it? Or is the @ enough? And should we do this for every PHP4-specific function we find in the code? Marc

1 0

[Phpmyadmin-devel] RC4
by Marc Delisle 07 Aug '01

07 Aug '01

Hi, About RC4 release, I was thinking that we should investigate various dump hangs/slow dumps errors before the release, but maybe we should get it out quickly because it fixes a security problem sent to BugTraq (and not to the developpers AFAIK:) Marc

1 0

[Phpmyadmin-devel] Re: MD5 for set fields in tbl_change?
by Loïc 07 Aug '01

07 Aug '01

Hi Steve! >we have a problem in tbl_change in line 251-252. OK, try to replace the line 250 by: <input type="hidden" name="fields[<?php echo urlencode($field); ?>]" value="$set$" /> (Just remove the echoing of $set in the value statement) Does it run with this fix? Loïc ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif

3 3

[Phpmyadmin-devel] dumps and php.ini
by Marc Delisle 07 Aug '01

07 Aug '01

Hi, if php.ini contains: output_buffering = On output_handler ="ob_gzhandler" Then a dump transmitted to a file, and not asked to be compressed, will be always compressed. Should we work around this? Marc

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Developers