✔ Neues in PHP 7

[filament]

Das ist so unfassbar: https://github.com/dshafik/php7-mysql-shim/blob/master/lib/mysql.php

Mal ganz doof (aus Sicht einer Person die sich eher hobbymäßig mit PHP / MySQL auseinandersetzt) gefragt, ohne das jetzt schön reden zu wollen:

Wenn ich mit den Befehlen arbeite und dann entsprechende Funktionen so generiere und es funktioniert, warum ist es dann schlecht? Hat das Performance Einbußen?

Ich sehe darin schon eine Zeitersparnis, weil ich nicht bei 10 Projekten sämtlichen Code neu machen muss.

(Nur zur Klarstellung: Ich ziehe das nicht in Betracht und werde mir die Arbeit machen. Aber ich würde gern wissen warum eine solche Lösung blöd ist?)

 

[sheel]

Was mir auf die Schnelle so einfällt...
(nicht nur harte technische Gründe, sondern auch andere störende Sachen):

Gründe dagegen, die für diese verlinkte Lib und auch für die "richtige" Mysql-Extension (die man mit einigen Umwegen auch bei PHP7 noch dazukompilieren kann) gelten, zuerst:

Geschwindigkeit

Sachen wie Prepared Statements, die man je nach Fall für Verschnellerungen verwenden kann, gibts nicht

PHP-Code-Probleme (Sicherheit & Funktionalität)

PHP-Code, der geschrieben wurde, als die Mysql-Extension noch gut war, funktioniert heute oft sowieso nicht mehr. PHP hat sich auch sehr verändert. Übrig bleibt PHP-Code, der geschrieben wurde, als es MysqlI usw. schon gab. Warum das so gemacht wird? Meistens, weil der Schreiber zu faul zum Lesen ist und sich den DB-Zugriff von irgendeinem der zig Millionen alten Anleitungen im Internet kopiert.
Problem dabei, die meisten davon sind grauenhaft schlecht. SQL-Injections, XSS? Richtige Datentypen? Null&Count, Autoincrement, Unique? Threadsicherheit und Transaktionen? Wird praktisch nie angesprochen oder auch nur erwähnt. Alles Sachen, wo Falschmachen auf den ersten Blick doch geht, später dann aber doch Probleme auftreten.

Änderungsaufwand

Diese Argument ist etwas gemein, aber: Wenn es schwer ist, den DB-Zugriff zu ändern, hat der Schreiber was in OOP verpasst. In dem Fall hilft Refractoring ihm selber auch, zumindest für die Wartbarkeit. Und durchs wirkliche Beschäftigen mit der Sache wird er obere Punkt (PHP-Code-Probleme) auch etwas mitigiert.

Weitere Gründe nur gegen die die verlinkte Lib:

Sicherheit

Wie ich das vor Monaten zum ersten Mal angeschaut habe hat es nur wenige Minuten gedauert, um eine grobe Sicherheitslücke zu finden. Die ist inzwischen vermutlich behoben, aber es dürfte nicht die einzige gewesen sein, wenn sowas Offensichtliches drinnen ist.
Und da man in der History usw. sehen kann, dass der Hauptauthor sogar mit dem richtigen Umgang mit isset überfordert ist, und andere Leute ihm dabei helfen müssen... wirklich vertrauenserweckend ist das nicht.

Geschwindigkeit

Noch etwas langsamer, weil durch das Wrappen einfach mehr Code ausgeführt werden muss.

API-Kompatibilität

Ohne Beweis, aber manche Stellen schauen verdächtig danach aus, dass
a) die PHP-Funktion sich in bestimmten Fällen nicht ganz gleich wie die originale alte Funktion verhält. Blöd, wenn der alte PHP-Code plötzlich was Anderes tut.
b) In der Implementierung innen MysqlI-Funktionen verwendet werden, als würden sie 100%ig das Selbe tun wie die gleichnamige alte mysql_ - Funktion. Das ist auch nicht immer der Fall.

Updates alter Software

Wenn man eine alte Version einer PHP-Software hat, laufend auf PHP5 mit den alten Mysql-Funktionen verwendet;
Dann macht der Hoster ein Update zu PHP7 und geht alles außer den DB-Sachen (unwahrscheinlich, aber kommt vor):
Es gibt genug Leute, die da zu faul sind, eine neue Version ihrer Software (samt Sicherheitsupdates) zu installieren, wenn sie diese Lib als Ersatz verwenden können => SIcherheitsproblem.

Weitere Gründe nur gegen die richtige Mysql-Extension:

Kompatibilität C/PHP

a) Das "richtige" Kompilieren und Installieren ist für einen durchschnittlichen PHP-Hobbyist viel zu schwer.

Spoiler: Mehr Text

Bedienen von Autotools selber, ca. 150 Configure-Flags (um eine Idee zu bekommen: https://dev.mysql.com/doc/mysql-sourcebuild-excerpt/5.1/en/source-configuration-options.html), Arch+ABI exakt für die richtige Version, Arten von Float/Exception/usw., das Zeug dann nicht als Root laufen lassen uvm.

Die möglichen Folgeprobleme beinhalten zB. Programmabstürze bei bestimmten Gelegenheiten (das netteste Problem), Sicherheitsprobleme (schlecht), oder einfach komplett falsches Verhalten (noch viel schlechter. Jede DB-bezogene Anweisung hat damit ein Risiko, einfach falsche Daten zu verarbeiten etc.).

b) Auch wenn man es ganz richtig geschafft hat könnte es durch jedes kleine PHP-Update wieder falsch werden. Die selben Probleme wie oben. Die übliche Lösung für einen Nicht-Umsteigen-Woller ist, PHP einfach nicht upzudatet, damit entgehen ihm auch alle Sicherheitsupdates für etwas, das ziemlich häufig angegriffen wird.

c) Irgendwann (oder auch schon jetzt) ist PHP soweit, dass eine richtige Kompilierung einfach gar nicht mehr geht, weil die Interfaces sich verändert haben, und man merkt es nicht. Evt. ist es auch jetzt schon so, keine Ahnung. Die möglichen Fehler sind so vielfältig, dass man es allein nie im Leben alles testen kann. Kurz, man sitzt freiwillig auf einer Zeitbombe.

Sicherheit Modul

Sicherheitslücken im Modulcode von Mysql (also nicht wegen falscher Bedienung, sondern wirklich falsch programmiert) werden nicht mehr gesucht und nicht ausgebessert. Und ich wette ziemlich viel, dass es etwas gibt, dass irgendeinem Kriminellen/Geheimdienst/etc. bekannt ist und ausgenutzt wird.

 

[filament]

Danke für die sehr ausführliche Antwort!

 

[bofh1337]

Keine Angst, die Hosting-Anbieter werden das schon noch nachrüsten. (Nein, keine Ahnung.)

Witziger finde ich, das "short_open_tags" entfernt wurde und die ganzen Copy&Paste-"Programmierer" sich gerade den Finger in den Hals stecken, weil sie es damals besser wissen mussten

 

[mermshaus]

Das wurde nicht entfernt. Siehe auch #20 in diesem Thread.

- https://github.com/php/php-src/blob/fcbf63d8087db46f2ecd9248687ef2a463013a14/php.ini-production#L197

Ist aber natürlich wahr, dass die Nutzung von <? nicht so die empfehlenswerte Idee ist.

Zu dem mysql-Shim:

Auch die Nutzung von so was ist natürlich nicht das Optimum. Konkret zur Qualität der verlinkten Lib kann ich zudem nichts sagen.

Grundsätzlich kann so was aber durchaus praktische Probleme lösen. Zum Beispiel in komplexen, lange bestehenden Projekten mit vielen Abhängigkeiten, die nicht so problemlos auf mysqli oder PDO umzuschreiben sind. Solche Libs haben deshalb schon eine Daseinsberechtigung. Den dadurch entstehenden Overhead würde ich auch als vernachlässigbar einstufen.

Andererseits stimmt es aber natürlich auch, dass es bei einem Wechsel auf PHP 7 realistisch auch noch andere Probleme geben könnte, die nichts mit der mysql-Erweiterung zu tun haben. Man müsste deshalb ein entsprechendes Szenario, das den Einsatz des Shims sinnvoll erscheinen lässt, doch recht stark konstruieren. Das ist wahrscheinlich doch eher akademisch.

 

[tklustig]

(Short-)Tags wurden entfernt. Die Erkennung für die Tags <% und <script language="php"> wurde entfernt.

HAHAHAAHA, unzählige Pfuscher werden an meine Worte von 2014 denken xD Hoffentlich ist dann auch sowas wie "<?=" als Tag ungültig

Nicht Dein Ernst, oder? Nutze dieses Shortcut anstatt einem

echo

schon seit längerem. Ein Rausschmiss würde meinen Code unbrauchbar machen....

 

[EuroCent]

Nicht Dein Ernst, oder? Nutze dieses Shortcut anstatt einem

echo

schon seit längerem. Ein Rausschmiss würde meinen Code unbrauchbar machen....

Auch wenn der Beitrag Alt ist:
Ich verwende fast ausschließlich <?= ?> Das erspart mir <?php echo ""; ?> voll auszuschrieben ;D
Genauso wie Ich IF Else Anweisungen kürze: $var = () ? "" : ""; => if() {} else {}

;D

 

[Jan-Frederik Stieler]

Der Ternary Operator ist aber kein Shortcut.

 

[EuroCent]

Der Ternary Operator ist aber kein Shortcut.

Das ist richtig

Wollte es aber dennoch angemerkt haben

 

[dreggert]

Hallo
Ich Wechsel nun von einem Anbieter zu einem anderen. Jetzt stehe ich vor dem Problem, dass ich mein altes PHP Tool was ich mal gebaut habe nicht mehr nutzen kann. Ich versuch das jetzt umzubauen um es wieder zum laufen zu bringen.
Hänge grad an den ganzen Ereg Ausdrücken.

if(ereg("\.[0-9]{1,}",$ges_kur)){
  $laenge = sprintf('%02.2f', $ges_kur);
  $kur_end_preis=str_replace('.', ',', $laenge);
 
}
else{
 $kur_end_preis = $ges_kur . ",00";
}

Grundidee ist hier zu prüfen, ob hinter dem Komma (z.B. 20.50) steht. Wenn nicht, soll nach dem Komma ,00 gesetzt werden.

Wie setze ich das sinnvoll um?
Ersetze ich das durch preg_match passiert nichts.