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

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.6.4 ist buggy – nicht für Sicherungen verwenden !

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.

phpMyAdmin Vers. 4.x und 5.x – Configuration Storage, Control User pma und zugehörige Tabellen

PhpMyAdmin hat sich ja seit der Version 4 dahingehend geändert, dass man seine Konfigurationseinstellungen für die GUI partiell in dafür bereitgestellten Datenbanktabellen hinterlegen muss. Hat man diese Tabellen nicht angelegt, weisen einen nach der phpMyAdmin-Grundinstallation Hinweise am unteren Ende der GUI auf bestehende Konfigurationsdefizite hin.

Ich vergesse nach der erfolgreich abgeschlossenen Einrichtung von phpMyAdmin auf einem Kundenserver leider selbst immer wieder, was genau man für die Einrichtung der “Konfigurationsdatenbank” und des zugehörigen Users im Rahmen der phpMyAdmin-Installation tun muss. Der Vorgang ist leider etwas umständlich. Wer immer sich diesen Installationsweg ausgedacht hat, sollte mal einen Kurs in Usability belegen.

Ich kritisiere dabei gar nicht die technische Umsetzung der Speicherung der Konfigurationseinstellungen für verschiedene User in Tabellen. Es geht mehr darum, welchen Aufwand man bei der Installation betreiben muss, um überhaupt ein konfigurierbares phpMyAdmin zu bekommen, das die vorgenommenen GUI-Einstellungen beim Verlassen des Programms nicht vergisst. Das ist wirklich keine Reklame für Opensource …. ganz im Gegensatz zu den schnörkellosen, einfach zu installierenden und gut zu bedienenden 3er-Versionen von phpMyAdmin.

Zudem ist die Basiseinstellung des 4er-GUI-Layouts in mancherlei Hinsicht einfach grässlich und im Vergleich zu den 3er-Versionen des Programms wenig ergonomisch. Daher schreibe ich die notwendigen Schritte hier mal auf.

Addendum 18.07.2022: Obwohl dieser Post ursprünglich für die Version 4.3 geschrieben wurde, gilt der Inhalt analog für aktueller Versionen 5.x.

Schritt 1: Einrichten der Konfigurationstabellen

Im Installationsverzeichnis von phpMyAdmin auf dem Web-Server – in meinem Fall

/srv/www/htdocs/phpmyad/

befindet sich ein Subverzeichnis “examples” mit folgender Datei:

examples/create_tables.sql

Addendum 18.07.2022: In einer aktuellen Version 5.2 von phpMyAdmin befindet sich die Datei im Verzeichnis “sql”.

Die Datei beinhaltet die notwendigen SQL-Statements zur Generierung der erforderlichen Tabellen. Zur Durchführung der Statements importiert man die Datei einfach mit phpMyAdmin:

phpmyad_1_600

Danach findet man folgende Tabellen einer neuen Datenbank “phpmyadmin” vor:

phpmyad_2

Addendum 18.07.2022: In aktuelleren Versionen von phpMyAdmin hat sich die Anzahl der Tabellen der Datenbank “phpmyadmin” erhöht:

Achtung:

Verwaltet man mit einer phpMyAdmin-Installation mehrere MySQL-Datenbank-Instanzen auf unterschiedlichen Datenbankservern, so muss man diesen Import-Schritt auf jeder Datenbank-Server–Instanz vornehmen!

Schritt 2: Anlegen eines Control-Users “pma”

Nun legt man mit Hilfe von phMyAdmin einen Datenbank-User “pma” an und erteilt ihm alle Rechte an der eben angelegten Datenbank “phpmyadmin”. Am einfachsten geht das über den Reiter “Rechte” bei geöffneter Datenbank “phpmyadmin”:

phpmyad_4_600

phpmyad_3_600

Dieser User mit den Rechten am sog. “Configuration Storage”, nämlich der Datenbank phpmyadmin, wird auch als “Control User” bezeichnet. Wir merken uns das vergebene Password. Auch diesen Schritt muss man natürlich für jede der mit der aktuellen phpMyAdmin-Installation ggf. verwalteten Datenbank-Server-Instanzen vornehmen.

Hinweis: Greift man nicht über “localhost” sondern einen Domainnamen auf phpMaAdmin zu, so muss der User pma auch für die Domaine angelegt werden, der der aktuelle Host zugeordnet ist. Also etwa

Create USER 'pma'@'mytux.mylocaldomain.de' IDENIFIED BY 'DEIN_PMA_PASSWORD';

Auch dieser User muss die nötigen Rechte an der Bank “phpmyadmin” erhalten.

Addendum 18.07.2022: Die Einschränkungen der Rechte des Users ‘pma’ durch die ersten Statements sind relativ restriktiv. Eine andere Wahl der Rechtezuteilung findet ihr hier:
www.workshop.ch/ openmind/ 2013/12/24/ phpmyadmin-zusatzfunktionen-aktivieren-mit-dem-configuration-storage/

Schritt 3: Ergänzung der Datei “config.inc.php”

Der nächste Schritt besteht darin, die Datei “confic.inc.php” im phpMyAdmin-Installationsvezeichnis des Webservers um Informationen zum User “pma” und zu den eben angelegten Konfigurationstabellen zu ergänzen:

$cfg['Servers'][$i]['pmadb'] = 'phpmyadmin';<br>
$cfg['Servers'][$i]['controluser'] = 'pma';<br>
$cfg['Servers'][$i]['controlpass'] = 'DEIN_PMA_PASSWORD';<br>
 <br>
$cfg['Servers'][$i]['bookmarktable'] = 'pma__bookmark';<br>
$cfg['Servers'][$i]['relation'] = 'pma__relation';<br>
$cfg['Servers'][$i]['userconfig'] = 'pma__userconfig';<br>
$cfg['Servers'][$i]['table_info'] = 'pma__table_info';<br>
$cfg['Servers'][$i]['column_info'] = 'pma__column_info';<br>
$cfg['Servers'][$i]['history'] = 'pma__history';<br>
$cfg['Servers'][$i]['recent'] = 'pma__recent';<br>
$cfg['Servers'][$i]['table_uiprefs'] = 'pma__table_uiprefs';<br>
$cfg['Servers'][$i]['tracking'] = 'pma__tracking';<br>
$cfg['Servers'][$i]['table_coords'] = 'pma__table_coords';<br>
$cfg['Servers'][$i]['pdf_pages'] = 'pma__pdf_pages';<br>
$cfg['Servers'][$i]['designer_coords'] = 'pma__designer_coords';<br>

Addendum 18.07.2022: In aktuelleren Versionen 5.x sieht das so aus:

/**
 * phpMyAdmin configuration storage settings.
 */

/* User used to manipulate with storage */
$cfg['Servers'][$i]['controluser'] = 'pma';
$cfg['Servers'][$i]['controlpass'] = 'YOUR_PMA_PASSWORD';

/* Storage database and tables */
$cfg['Servers'][$i]['pmadb'] = 'phpmyadmin';
$cfg['Servers'][$i]['bookmarktable'] = 'pma__bookmark';
$cfg['Servers'][$i]['relation'] = 'pma__relation';
$cfg['Servers'][$i]['table_info'] = 'pma__table_info';
$cfg['Servers'][$i]['table_coords'] = 'pma__table_coords';
$cfg['Servers'][$i]['pdf_pages'] = 'pma__pdf_pages';
$cfg['Servers'][$i]['column_info'] = 'pma__column_info';
$cfg['Servers'][$i]['history'] = 'pma__history';
$cfg['Servers'][$i]['table_uiprefs'] = 'pma__table_uiprefs';
$cfg['Servers'][$i]['tracking'] = 'pma__tracking';
$cfg['Servers'][$i]['userconfig'] = 'pma__userconfig';
$cfg['Servers'][$i]['recent'] = 'pma__recent';
$cfg['Servers'][$i]['favorite'] = 'pma__favorite';
$cfg['Servers'][$i]['users'] = 'pma__users';
$cfg['Servers'][$i]['usergroups'] = 'pma__usergroups';
$cfg['Servers'][$i]['navigationhiding'] = 'pma__navigationhiding';
$cfg['Servers'][$i]['savedsearches'] = 'pma__savedsearches';
$cfg['Servers'][$i]['central_columns'] = 'pma__central_columns';
$cfg['Servers'][$i]['designer_settings'] = 'pma__designer_settings';
$cfg['Servers'][$i]['export_templates'] = 'pma__export_templates';

Man beachte dabei, dass es zwischen dem Prefix “pma” und dem Tabellennamen 2 (!) Unterstriche gibt.

Im diskutierten Beispiel sind wir davon ausgegangen, dass wir die Serverinstanz mit dem Index “$i” mit den Informationen versorgt haben.

Natürlich gilt auch hier, dass man diese Einstellungen separat pro MySQL-Datenbankserver-Instanz, die mit phpMyAdmin verwaltet werden soll, anlegen muss. Sind mehrere Instanzen gegeben, ist es also wichtig, im Script “config.inc.php” den Index $i explizit hochzuzählen bzw. auf den richtigen Wert für die jeweilige Instanz zu setzen.

Man verlässt dann phpMyAdmin und loggt sich erneut in die GUI ein. Es sollten nun keine Hinweise mehr zu Konfigurationsdefiziten erscheinen.

Schritt 4: Vornehmen von Änderungen

Wir sind nun in der Lage, die gewünschten Änderungen am GUI-Layout pro Serverinstanz vorzunehmen und dauerhaft in den angelegten Tabellen zu hinterlegen. Als Beispiel ändern wir die parallele Anzeige von Icons und Menüpunkt-Texten auf den Seiten zur Bearbeitung der Tabellen so ab, dass nur noch die Icons angezeigt werden:

phpmyad_5_600

Nicht vergessen, den Button “Speichern” zu drücken. Ganz so praktisch und informativ wie die GUIs der 3er-Version wird phpMyAdmin in der Version wohl erst wieder nach einiger Zeit werden.

Trotzdem viel Spaß beim künftigen Herumprobieren mit eigenen Einstellungen in den aktuellen Versionen von phpMyAdmin.

Adendum 18.07.2022: Bevor ich es vergesse: Der schlimmste lebende Faschist und Kriegsverbrecher ist der Putler!