MySQLnd is not being used for database communication.

Outrush · February 9, 2018 at 10:26 AM

Bekomme ich als Meldung bei der Installation der RC3.

**Alexander Ebert** · February 9, 2018 at 10:28 AM Official Post

Für den Betrieb ist der "Native Driver" für MySQL notwendig, bei einigen Control-Panels läuft die PHP-Erweiterung unter der Bezeichnung nd_pdo_mysql.

Outrush · February 9, 2018 at 11:03 AM

Ist das jetzt seit der RC3 so oder auch schon bei RC 1 u 2 ?

**Alexander Ebert** · February 9, 2018 at 11:18 AM Official Post

Diese Voraussetzung besteht bereits seit WCF 2.0, aber war bis jetzt nie explizit erfasst, da die üblichen MySQL-PDO-Binaries stets mit dem Native Driver liefen - dieser wird explizit auch von den PHP-Entwicklern empfohlen. Wir haben aber beobachtet, dass seit kurzem einige Control-Panels zusätzlich zur Extension auf Basis des Native Drivers noch die alternative Extension anbieten, letztere aber als "pdo_mysql" firmieren lassen. Ergo ist es notwendig, diese Voraussetzung korrekt zu dokumentieren und bei Bedarf die weitere Installation zu blockieren.

Bitte wende dich an deinen Anbieter, damit die korrekte PDO-MySQL-Erweiterung geladen wird.

Outrush · February 9, 2018 at 11:20 AM

Nö, ich benötige in Zukunft kein neues WBB mehr.

Schönen Tag noch.

**Alexander Ebert** · February 9, 2018 at 11:35 AM Official Post

Es handelt sich hierbei lediglich um eine Systemvoraussetzung, die für den einwandfreien Betrieb notwendig ist. Die alternative MySQL-Erweiterung, die nicht auf dem Native Driver von MySQL basiert, verursacht ein abweichendes Verhalten von MySQL, bzw. die Rückgabewerte von Datenbank-Abfragen entsprechen nicht mehr den erwarteten Typen. In Folge dessen kommt es an mehreren Stellen zu Fehlern, durch die die Funktionsweise beeinträchtigt wird, im Übrigen betrifft dies möglicherweise auch frühere Versionen unserer Software.

Dies ist keine neue Voraussetzung, sondern eine die implizit bereits bestand, aber nicht explizit abgefragt wurde, da normalerweise der Native Driver für MySQL zum Einsatz kommt.

Der Native Driver ist seit PHP 5.4 der empfohlene Standard für die MySQL-Erweiterung (bzw. seit PHP 5.3 unter Windows), d. h. um diese Erweiterung nicht einzusetzen, muss explizit vom Standard abgewichen werden. (Siehe auch https://secure.php.net/manual/de/mysq…ry.choosing.php)

Outrush · February 9, 2018 at 11:48 AM

Quote from Alexander Ebert

Es handelt sich hierbei lediglich um eine Systemvoraussetzung, die für den einwandfreien Betrieb notwendig ist.

Dann schreibt es gleich ganz vorne hin und nicht erst bei der Eingabe der Serverdaten.

Ich frage mich warum bisher alles einwandfrei lief, obwohl ... es spielt ja keine Rolle mehr.

Jack Valentine · February 10, 2018 at 9:08 AM

Quote from abgpeter

Ich frage mich warum bisher alles einwandfrei lief

weil man wohl jetzt auf den Trichter gekommen ist neue Knüppel den Kunden zwischen die Beine werfen zu können. Wenn WoltLab vorher nicht explizit abgefragt hat, könnten sie dies auch weiterhin nicht tun, was sie aber nicht wollen und so dem Kunden Probleme weiterreichen.

cab10 · February 10, 2018 at 10:04 AM

Quote from Serana

weil man wohl jetzt auf den Trichter gekommen ist neue Knüppel den Kunden zwischen die Beine werfen zu können. Wenn WoltLab vorher nicht explizit abgefragt hat, könnten sie dies auch weiterhin nicht tun, was sie aber nicht wollen und so dem Kunden Probleme weiterreichen.

Das ganze soll doch Probleme verhindern.

Wenn es dann Probleme während des laufenden Betriebes gibt wird dann wieder rumgeheult warum solche Sachen nicht bei der Installation abgefragt werden.

Lieber schon vornerein potentielle Probleme beheben.

Kann man diese Meldung eigentlich *ignorieren* oder funktioniert die Installation dann nicht? Man könnte ja zulassen das es sich trotzdem installieren lässt, der Admin darf sich aber hinterher nicht beschweren wenn etwas nicht richtig funktioniert.

Mich würde interessieren welche Controlpanel kein mysqlnd in pdo_mysql haben. Bei mir ist alles korrekt.

Teralios · February 10, 2018 at 10:30 AM

Quote from abgpeter

Dann schreibt es gleich ganz vorne hin und nicht erst bei der Eingabe der Serverdaten.

Ich frage mich warum bisher alles einwandfrei lief, obwohl ... es spielt ja keine Rolle mehr.

So unschön es für dich selbst an dieser Stelle ist: WoltLab trifft hier keine Schuld, sondern primär deinen Hoster, bei dem du dich beschwere solltest.

Quote from Serana

weil man wohl jetzt auf den Trichter gekommen ist neue Knüppel den Kunden zwischen die Beine werfen zu können. Wenn WoltLab vorher nicht explizit abgefragt hat, könnten sie dies auch weiterhin nicht tun, was sie aber nicht wollen und so dem Kunden Probleme weiterreichen.

Man wirft hier nicht wirklich einen Knüppel zwischen die Beine der Kunden, sondern versucht die eigene Software so gut es geht "vorhersehbar" zu machen und auch auf die Zukunft vorzubereiten.

Das WSF und damit das WSC setzten zwar aktuell noch "nur" PHP5.5 voraus, doch PHP5.5 ist "End of Life" und PHP5.6 wird am 1. Januar 2019 folgen. Ab nächstem Jahr sind die Versionen, die noch offiziell gepflegt werden PHP7.1, 7.2 und das wohl in diesem Jahr erscheinende 7.3. Mit PHP7.0 kamen einige sehr schöne Funktionen dazu um PHP-Code saubere zu schreiben, als es aktuell in PHP5.x der Fall ist und dazu gehören auch, dass man Parameter als auch Rückgabewerte von Funkionen endlich typisieren kann an.

Wenn jetzt aber der MySQL-Treiber nicht mit spielt, weil er unzuverlässige "Typen" zurück liefert, kracht es spätestens an dem Punkt, wenn man die Daten aus der Datenbank als Parameter übergibt.

Code

function checkVar(int $i, string $text, float $n)
{
    // ...
}
$statement = WCF::getDB()->prepare("SELECT 1, 'Text', 1.23");
$statement->execute();
$row = $statement->fetch();
checkVar($row[0], $row[1], $row[2]);

Wenn nun der MySQL-Treiber irgendwelche "Typen" zurück gibt, dann kommt es jetzt in PHP zu folgender Meldung:

"Argument 1 passed to checkVar() must be of the type integer, string given, called in C:\Users\achterrath\PhpstormProjects\commentarius\public\test.php on line 7"

Gerade, wenn man declare(strict_types=1)nutzen möchte um das Skript sauberer und sichere zu machen. Denn von diesem Zeitpunkt aus, muss man jedem "Rückgabetyp" aus der Datenbank misstrauen und ihn erst mal zum richtigen Type wandeln. Das bläht den Quelltext unnötig auf und verlangsamt das Script sogar spürbar, da ja diese Aufrufe nicht nur "einmalig" erfolgen, sondern für jeden Datensatz aus der Datenbank und Kleinvieh macht bekanntlich eben auch Mist.

Jack Valentine · February 10, 2018 at 5:41 PM

Quote from Teralios

Man wirft hier nicht wirklich einen Knüppel zwischen die Beine der Kunden, sondern versucht die eigene Software so gut es geht "vorhersehbar" zu machen und auch auf die Zukunft vorzubereiten.

Was ich nicht verstehe und zu Recht auch bemängel ist die fehlende Information darüber. Es bricht sich WoltLab keinen Zacken aus der Krone diese kleinen Veränderungen zur vorherigen Version deutlicher mit zu teilen. (zB. in der Mindestanforderung oder Installationsanweisung)

Outrush · February 10, 2018 at 10:54 PM

Quote from Teralios

So unschön es für dich selbst an dieser Stelle ist: WoltLab trifft hier keine Schuld, sondern primär deinen Hoster, bei dem du dich beschwere solltest.

Du verstehst es nicht oder?

Ich habe nichts gegen Änderungen an der Systemvorraussetzungen, wenn es besser, sicherer, schneller, sauberer läuft , ich bin dafür.

Aber sagt es mir bitte vorher und alles gut.

Ich habe die RC2 gelöscht, die ich ja bis dato am testen hatte.

Installiere nun die RC3 und bekomme erst bei der Eingabe der Serverdaten den besagten Hinweis, und die RC3 lässt sich nicht installieren.

Das bemängele ich, nichts anderes.

Irgendein vorheriger Hinweis wäre nicht schlecht gewesen.

Outrush · February 10, 2018 at 11:31 PM

Achja, hat sich erledigt, kann geschlossen werden.

Danke.

SoftCreatR · February 10, 2018 at 11:38 PM

Ich verstehe diese ganze Diskussion nicht. Davon abgesehen, dass diese Voraussetzung schon seit Ewigkeiten existiert (2013?), ist es doch fast egal, wann auf die Erfüllung selbiger geprüft wird. Und wenn du meinst, dass das eher ungünstig ist, dass das erst so spät passiert, dann reich es halt als Vorschlag ein und gut ists?

PS: Themen werden auf Anfrage nicht einfach geschlossen.

Outrush · February 10, 2018 at 11:55 PM

Quote from SoftCreatR

Ich verstehe diese ganze Diskussion nicht.

Doch hast du.

Quote from SoftCreatR

Und wenn du meinst, dass das eher ungünstig ist, dass das erst so spät passiert,

Genau darum gehts.

Das es am Server liegt, bzw an meine Konfiguration ist mir inzwischen klar.

Quote from SoftCreatR

PS: Themen werden auf Anfrage nicht einfach geschlossen.

Siehst du dort eine Anfrage?

Quote from abgpeter

Achja, hat sich erledigt, kann geschlossen werden.

Danke.

Das war ein Hinweis, das Problem ist gelöst.

Ob der Admin oder Mod das nun schließt, dass bleibt ihnen überlassen.

Morik · February 11, 2018 at 10:15 AM

Quote from abgpeter

Installiere nun die RC3 und bekomme erst bei der Eingabe der Serverdaten den besagten Hinweis, und die RC3 lässt sich nicht installieren.

Es lässt sich leider erst durch den Rückgabe-Wert einer MySQL-Abfrage klären ob der richtige Treiber geladen ist und die kann man erst absenden wenn gültige Zugangsdaten eine entsprechende Abfrage überhaupt ermöglichen.

Leider kann man hier nicht einfach die Module befragen da ja genau das Problem besteht dass ein Modul mit einem abweichenden Treiber plötzlich benannt ist wie das eigentlich benötigte...

Outrush · February 11, 2018 at 12:05 PM

Quote from Morik

Es lässt sich leider erst durch den Rückgabe-Wert einer MySQL-Abfrage klären ob der richtige Treiber geladen ist und die kann man erst absenden wenn gültige Zugangsdaten eine entsprechende Abfrage überhaupt ermöglichen.

Das ist doch mal Aussage, dann nehme ich alles Jammern zurück, Danke und Sorry.

**Alexander Ebert** · February 11, 2018 at 12:29 PM Official Post

Das Problem ist im wesentlichen folgendes: Die PHP-Erweiterungen mysqli und pdo_mysql sind für den Zugriff auf MySQL zuständig, diese stellen die entsprechenden Funktionen für die Kommunikation mit der Datenbank bereit. Diese kommunizieren aber selbst wieder nicht direkt mit MySQL, sondern deligieren diese Aufgabe an eine Implementierung im Hintergrund:

Code

PHP-Code <-> pdo_mysql <-> MySQL-Treiber <-> MySQL

Und genau hier liegt der sprichwörtliche Hund begraben, denn es gibt zwei verschiedene MySQL-Treiber in PHP:

libmysqlclient
Der ursprüngliche Treiber der bis PHP 5.3 verwendet wurde und von MySQL selbst stammt.
mysqlnd
Der "Native Driver" wurde mit PHP 5.3 bzw. 5.4 eingeführt und ist libmysqlclient in so ziemlich allen Belangen überlegen. Er verbraucht weniger Ressourcen, erlaubt Anpassungen und liefert möglichst typengetreue Rückgabewerte (ein Integer in der Datenbank ist am Ende auch ein Integer in PHP).

Der mysqlnd-Treiber ist der Standard unter PHP und wird sowohl von PHP als auch von MySQL (!) explizit empfohlen. Wenn man die fertigen Binaries für PHP bzw. die PHP-Pakete der Linux-Distributionen verwendet, so erhält man stets die mysqlnd-Version, da es keinen sinnvollen Grund gibt, auf die alte libmysqlclient-Implementierung zurückzugreifen - zu mindestens so weit mir bekannt.

Der Knackpunkt an dieser Angelegenheit ist, dass der MySQL-Treiber etwas ist, dass im verborgenen statt findet und nach außen hin nicht ersichtlich ist. Aus Sicht des PHP-Codes ist beides mysqli bzw. pdo_mysql, denn deren Methoden sind stets gleich, es gibt nicht mal eine eingebaute Methode (*), um den verwendeten MySQL-Treiber zu erkennen. Allerdings unterscheidet sich das Verhalten der beiden MySQL-Treiber, wodurch man erst bei der Interaktion mit der Datenbank bemerkt, dass irgendetwas nicht ganz stimmt. Mit PHP wird es halt nie langweilig

Unser Fehler an dieser Stelle war das implizite Vertrauen darauf, dass im Hintergrund stets mysqlnd verwendet wird. Es ist bislang nur unentdeckt geblieben, da bei allen relevanten Systemen dies auch der Fall war und somit auch immer alles gepasst hat.

(*) https://github.com/php/php-src/bl…o_test.inc#L166

jens1o · February 11, 2018 at 1:03 PM

Quote from Alexander Ebert

Der Knackpunkt an dieser Angelegenheit ist, dass der MySQL-Treiber etwas ist, dass im verborgenen statt findet und nach außen hin nicht ersichtlich ist. Aus Sicht des PHP-Codes ist beides mysqli bzw. pdo_mysql, denn deren Methoden sind stets gleich, es gibt nicht mal eine eingebaute Methode (*),

Schreibt doch einen RFC

Participate now!