Category Archives: phpMyAdmin

Erfahrungen mit phpMyAdmin

phpmyadmin, charts, MariaDB – a strange bug with x-axis value order and ORDER clauses in sub-SELECTS

Posted on by

A customer of mine wants to use phpMyAdmin to create some charts whilst working with a complex database. I recommended a trial with phpMyAdmin and its chart functionality. Unfortunately, this did not always work out as expected:

You may e.g. create an ordered resultset first – with a suitable SELECT and ORDER clause – e.g. to get two columns – an index “i” and associatd values “val”. Rows of the resultset ordered e.g. ASC with the “i”-values. But after using the columns “i” a simple line graph the order on the x-axis may appear different than requested by your ORDER clause.

I have posted this as an issue to the (nice) developers of phpmyadmin – who are working on it :-).

There is a workaround. But what I found more interesting is the cause of the problem, which appears on MariaDB and NOT on MySQL. It has apparently to do with a different handling and interpretation of SQL standards for ORDER clauses in sub-SELECTs! See:
https://mariadb.com/kb/en/library/why-is-order-by-in-a-from-subquery-ignored/

This is of general interest for developers using MySQL or MariaDB-databases. I, myself, was not aware of it. Besides an already different handling of database replication, I regard this point as one more indication for a growing “distance” between both RDBM-systems…

If you stumble across the phpmyadmin-chart problem, see a discussion and a workaround on the following site:
https://github.com/phpmyadmin/phpmyadmin/issues/14239

I also want to explicitly thank M. Jayaratne who supplied me with the valuable information referenced above.

PhpMyAdmin 4.7 on Opensuse Leap 42.2 – install PHP 7 and correct some code to avoid errors

Posted on by

Yesterday, I wanted to change to the latest version of PhpMyAdmin (4.7) on my development laptop which runs on Opensuse Leap 42.2. PHP 5.6 was provided via an Apache2 server and php-apache-modules. I downloaded the zipped code package for PhpMyAdmin and performed the usual setup procedure on my local web server. But I met some obstacles both under and after the phpmyadmin installation.

First, I got an error during installation of the following type:

phpmyadmin fatal error: call to undefined function phpseclib\crypt\random::string() in …/phpmyadmin/libraries/config/serverconfigchecks.php on line 226

Changing to PHP 7 – via using the Opensuse repository at http://download.opensuse.org/repositories/devel:/languages:/php/openSUSE_Leap_42.2/ helped to overcome this error.

However, be aware of the fact that changing to PHP 7 globally implies a lot of consequences – e.g changing database code in older programs from the the “mysql” to the “mysqli” interface. (Off topic: As long as one wants to use PHP via Apache modules I do not see a way to run both PHP versions in parallel on one Apache2 web server. Things are different with FCGI and PHP-FPM; but I did not experiment with these alternatives, yet. My way to support older programs for the time being actually includes the use of an independent 42.2 LAMP installation on a KVM machine – together with an older 4.3/4.4-version of PhpMyAdmin.]

Another error I stumbled across after installation of PhpMyAdmin 4.7 occured when I tried to use the drop-down boxes for changing pages during the display of large tables. Whenever you use the drop down box a small popup appears complaining about “unmatching tokens”.

The recipe to mend this bug is described by the Phpmyadmin developers on the following Internet page:
https://github.com/phpmyadmin/phpmyadmin/commit/5ee4320b7de345062ced7e02aca65417baa8a944

One just has to change some lines (at line nr 796) in the file “/InstallationDirOFPhpmyadminOnWebserver/libraries/DisplayResults.php” as described in the above article : 

// Comment the following lines at position 796 and replace with the 2 lines shown 
// $table_navigation_html .= '<form action="sql.php'
// . URL::getCommon($_url_params)
// . '" method="post">';
$table_navigation_html .= '<form action="sql.php" method="post">';
$table_navigation_html .= URL::getHiddenInputs($_url_params);

Good luck with PhpMyAdmin 4.7!

phpmyadmin 4.6.4 ist buggy – nicht für Sicherungen verwenden !

Posted on by

Ich hatte heute die Aufgabe, die Daten eines WordPress-Blogs von der MySQL-Datenbank eines Hosting Providers zu sichern und den Blog dann auf eine neue Datenbank bei einem anderen Provider umzuziehen. Dabei hat ein übler Bug in der phpMyAdmin-Version 4.6.4 etliche meiner Nerven verschlissen:

Auf Exports von Tabellen mit Kommentaren oder Spalten mit bestimmten HTML-Inhalten kann man sich bei der aktuellen Version (Stand 03.10.2016) leider nicht verlassen; der nachfolgende Import scheitert unter Umständen – vermutlich wegen einer fehlenden oder fehlerhaften Maskierung von Anführungszeichen.

Es dauerte aber eine ganze Weile, bis ich anfing, der Exportfunktion von phpMyAdmin zu misstrauen – vor allem, weil mir bei dem Provider keine Datenbank-Logs zur Verfügung standen. Ich konnte den Fehler aber an einer reduzierten “posts”-Testtabelle der WordPress-Installation nachvollziehen; der Export und nachfolgende Import schlägt mit der Version 4.6.4 reproduzierbar fehl – in meinem Fall sogar mit einem internen Server-Error.

Gott sei dank war die alte Datenbank noch nicht gelöscht! Ich konnte den Export/Import-Vorgang mit der auf die Schnelle installierten phpMyAdmin-Version 4.4.15.8 anschließend anstandslos und fehlerfrei durchführen.

Solche Bugs können üble Folgen haben, wenn man nach einer “Sicherung” naiverweise den alten Datenbank-Zustand löscht, ohne vorher an einer anderen Datenbank den Reimport getestet zu haben. Auch für phpMyAdmin gilt bei Sicherungen die alte Regel:
Immer erst die ganze Kette zur Restaurierung testen, bevor man irgendetwas löscht!

Dennoch: So ein Bug ist wirklich übel! Ich bin ein wenig sauer …. im Nachhinein fand ich dann unter github folgende Bug-Einträge:
https://github.com/phpmyadmin/phpmyadmin/issues/12086
https://github.com/phpmyadmin/phpmyadmin/issues/12453
Der erste davon wurde geschlossen, obwohl er offenbar immer noch oder wieder vorhanden ist.