The phpMyAdmin development team are pleased to announce the release of the
latest stable version, 2.3.0.
Changes since 2.2.6:
UTF-8 support
Syntax coloring of SQL statements
Schema output in PDF
Print view for SQL results
EXPLAIN support
Full database search
IP-based Allow/Deny
XML export
New SQL Parser
New Languages: Slovenian, Afrikaans, Hindi
Lots of bug fixes.
Packages are ready under http://www.phpmyadmin.net/
Please report bugs to the -devel mailing list or on the tracker under:
http://sourceforge.net/tracker/?atid=377408&group_id=23067&func=browse
We have also released 2.2.7 without the new features, but with the bug
fixes found in 2.3.0.
Regards,
Robin, Marc, Loïc, Alexander, and the rest of the development team.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
> 2. We should deprecate the user/password standard login, or add a bit of
> technology to it. We should throw up a login page of our own, that should
> authenticate against a user/password pair in an array inside the
> configuration file. It might be possible to keep the automatic login of
> user/password, but it should not be enabled by default, for security.
> And the configuration option to turn that unsecure method back on should
> have huge warnings around it.
i agree there, actually i was rather shocked to read an article about
phpMyAdmin in the german 'Linux Magazine' last week where they talked about
how to configure it and said, that usually it is ok to leave the standard
entry of 'root' (without a password) there! So that guy writing the article
seems to think it is normal to set up a MySQL Server without giving a
password for root and he understands our config.inc.php3 to suggest it
should be like that... well i think i'll send them a readers letter but also
we should change the doku and the config.inc. to more explicitely propose
using of http or cookie protection.
regards
mike
Hi Robin & List:
I've found another bug in the string sorter. Take a look at the way it sorts
the "revoke" strings for example:
$strRevokeGrantMessage
$strRevokeGrant
$strRevokeMessage
$strRevokePriv
$strRevoke
Happy fixing,
Alexander
Hi list,
I've been looking at the bug list, trying to see what remaining stuff is
really important.
The only one I see is:
#590055 (2.3.0-rc4) Empty Corrupts Tables
Other ones that I think are important, but not showstoppers are:
#592950 (2.3.0-rc4) Bug at creation of PHP code from SQL
#589688 (2.3.0-rc4) INSERT from TEXTFILE erases filename
#582890 requires hostname for socket connection
Rabus just needs to finish with #590055, and then I think we are all set
to go in terms of bugs being fixed.
I'm still working on the Documentation myself presently.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi List,
I was getting very annoyed at re-arranging language files by hand once I
got new translations, so I sat down and wrote two more scripts for the
language directory.
lang/sort_lang.sh:
Resorts a language file to make it neat and tidy, with blank lines
between groups of alphabetical order strings.
File contents order:
HEAD (everything that doesn't match other stuff) chunk
translated chunk (matching '^[[:space:]]*\$str[[:alnum:]_]*')
untranslated chunk (matching '//.*translate.*$' case-insensative)
Now if we want to merge new languages or language strings easily, just
dump your translated strings into the file, delete the english strings
they replace, and run the sort_lang script on the file. 8-)
lang/check_lang.sh:
Checks for duplicate or missing strings in the language files.
>From using this, I see that there are few duplicated strings in some
language files that should get fixed in 2.3.1, as well as some language
files are missing strings that are in the english file.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Greetings,
I'm busy revamping the BUG() code in the SQL Parser, including making
things more PHP3 compatible, and putting the strings into the lang/* files
instead of inside the main sqlparser, so they they can be translated.
There is one major functionality change. The existing -rc4 and CVS code
did a die() call on a failure of the parser, I did that for the moment to
strongly encourage bug reports. I've got them fixed now, so the behaviour
is changing just to printing out the error message from the parser system,
and carrying on doing whatever else was being done.
At the moment, the BUG() code has been abstracted to PMA_SQP_BUG() in the
SQLParser library, but in 2.3.1 or otherwise soonish, PMA will gain a
proper BUG() function.
My PMA_SQP_BUG() presently includes:
Error Message
CVS $Id$ of sqlparser
MySQL version
User OS/Browser/BrowserVersion
PMA version
PMA version/OS
SQL query
Do you have any other suggestions of things that might be handy to have in
tracking down bugs?
There is also PMA_SQP_throwError() for when you want to inform the user of
a possible error on their part, that is not an error with our code.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi List,
I'm busy updating the documentation for the final release on sunday. I
still have a few sections to do, namely the stuff about the SQL Validator,
but other than that, it documented all of the changes regarding the SQL
Parser, as well as put in documentation about configuration variables that
were in the config.inc.php3 file, but not the documentation, and I have
re-arranged the configuration file and Documentation Configuration section
some so that the variables all come in the same order.
>From having to deal with the size that the documentation is getting, I
really think that it is time it got easier to manage. On those lines, I'm
going to work on an XML documentation system for 2.3.1, to make
everybody's life easier. I plan to use XSLT + XML Schema to ensure well
formed documentations that are easily converted to HTML/Text/PDF etc.
Either that setup, or I will take a look at DocBook, since it is a fairly
common standard as well.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
