> > - 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...
> > - 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.
> 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
> > - 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/
:)))
> 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...
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 ü
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
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
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
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
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