PHP7.0 und DOMDocument ist immer noch kaputt!
Felix Riesterer
PHP7.0 und DOMDocument ist immer noch kaputt!
Felix Riesterer
Liebee Mitlesende,
habe heute mein Webprojekt für PHP7 flott gemacht. Am Script selbst musste ich rein überhaupt nichts ändern. Aber was mich extrem nervt, ist diese kaputte libxml-DOMDocument-Geschichte, die man getrost einfach nur als kaputt bezeichnen kann.
Warum? Wenn man ein in UTF-8 kodiertes HTML-File einliest, dann kann man es nicht korrekt an den Browser senden, denn sowohl DOMDocument::saveHTML als auch DOMDocument::saveHTMLFile machen Murks.
Echt nur noch zum Kotzen! Und das nach über zehn Jahren Entwicklungszeit!!
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix,
Echt nur noch zum Kotzen! Und das nach über zehn Jahren Entwicklungszeit!!
Ja, es ist total zum kotzen! Man sollte sie verklagen, sie haben schließlich auch eine Gewährleistungspflicht! Ich meine, es ist ja nicht so als stünde das alles unter einer freien Lizenz und man könnte sich selbst darum kümmern, dass das gefixed wird!! Oh, wait…
Open Source bedeutet nicht, dass man die Komponenten kostenfrei nutzen darf und ansonsten die gleichen Ansprüche an enen Hersteller haben darf, wie bei proprietärer Software. Open Source bedeutet auch, dass man die Pflicht hat sich um Fehler zu kümmern, Bugreports einreichen muss oder auch mal selber einen Patch schreiben muss. Wenn dich das Verhalten stört, dann schreibe einen Patch und/oder kommuniziere mit den Entwicklern, warum das so ist, wie es ist und versuche sie zu überzeugen, dass sie falsch liegen.
Ansonsten finde ich es gerade bei den von dir erwähnten Methoden schwierig von kaputt zu reden. Erstens wird es nicht auf PHP zurückzuführen sein sondern auf libxml und zweitens finde ich, dass sie sich hier Standard-konform verhalten. HTML-Parser müssen fehlende Tags ergänzen, siehe auch den Parsing-Algorithmus von HTML5.
LG,
CK-
Lieber Christian,
Ja, es ist total zum kotzen! Man sollte sie verklagen, sie haben schließlich auch eine Gewährleistungspflicht! Ich meine, es ist ja nicht so als stünde das alles unter einer freien Lizenz und man könnte sich selbst darum kümmern, dass das gefixed wird!! Oh, wait…
;-)
wird es nicht auf PHP zurückzuführen sein sondern auf libxml
Gestern war ich zu müde, um an libxml im Besonderen zu denken und zu prüfen, ob meine lokale Testumgebung und die Produktionsumgebung dieselbe Version von libxml nutzen - was natürlich mal wieder nicht der Fall war. Mail an den Support ist unterwegs.
und zweitens finde ich, dass sie sich hier Standard-konform verhalten. HTML-Parser müssen fehlende Tags ergänzen, siehe auch den Parsing-Algorithmus von HTML5.
Ach, mich stört das zusätzliche Tag nicht, wenn meine Umlaute nicht verstümmelt würden. Alles ist intern UTF-8, nur der Output zeigt verstümmelte non-ASCII-Zeichen mit wilden HTML-Entitäten. Das hat mich aufgeregt. Auf meinem Testsystem (libxml 2.9.1) passiert das nämlich nicht. Und einen echten HTML5-Parser wollte ich für ein so winziges Projekt nicht bemühen.
Liebe Grüße,
Felix Riesterer.
-
-
Echt nur noch zum Kotzen! Und das nach über zehn Jahren Entwicklungszeit!!
Ich teile deinen Frust. PHPs nativen Möglichkeiten zum Umgang mit HTML sind erschreckend untauglich. Die DOM-API ist an sich schon nicht besonders umgänglich, aber die PHP-Implementierung im besonderen Maße. Auf der anderen Seite ist String-Konkatenation auch keine Alternative, weil dadurch jede Struktur- und Typinformation verloren geht. Zudem ist das vermutlich der Ursprung für 99% aller XSS-Sicherheitslücken. Darüber habe ich mich kürzlich noch @Der Martin unterhalten. Zum Glück hat PHP eine sehr aktive Community und man kann zwischen endlosen Templating-Engines wählen. Dennoch kommt PHP mir manchmal wie eine Sprache für Webentwickler vor, die mit Webtechnologien eigentlich nichts am Hut haben wollen. Meine Begeisterung erntet deshalb das Hacklang-Projekt und insbesondere die XHP-Schnittstelle. Das zeigt wie einfach HTML schreiben kann:
echo <h1>Hello, {$name}!</h1>;Im wesentlichen ist XHP das PHP-Äquivalent zu JSX.