Markus Baersch

Software · Beratung · Lösungen

Suche im Blog

Sign In

Saturday, 29 June 2013

Störungen auf der Website nach PHP-Umstellung bei 1und1 behoben...

Es hat ein wenig gedauert, bis ich überhaupt darauf aufmerksam gemacht wurde, aber nach dem "Zwangsupdate" meines Hostingpakets bei 1&1 hatte ich (nach kurzen Problemen, die ich mir per .htaccess-Anweisung eingefangen hatte) eigentlich gedacht, dass alles funktioniert.

Falsch: Sowohl das Tool zur Bereinigung von Seitenquellcode als auch das Kontaktformular hat leider nicht immer funktioniert. Je nach Nachricht bzw. umzuwandelndem Text gab es Störungen, die ich nun mit einiger Mühe auf "verschwundene" Variablenwerte zurückgeführt habe. Die Ursache: wer wie ich von htmlentities() oder htmlspecialchars() Gebrauch macht, sollte wissen, dass nun ein anderer Zeichensatz (natürlich utf-8) als Voreinstellung gilt und so wird durch die anderen - ebenso nicht gesetzten und mit neuen Defaults versehenen Optionen - schnell aus einem String ein Nichts. Leerzeichen an der falschen Stelle oder Umlaute sind typische Auslöser. Das Problem ist - einmal gefunden - aber schnell zu beheben, indem alle Aufrufe angepasst werden, um das bisherige Verhalten wiederherzustellen.

Aus...

htmlentities($txt);

... wird dazu...

htmlentities($txt, ENT_COMPAT,'ISO-8859-1', true);

... und schon ist das Problem vermutlich behoben. Wer also ähnliche Probleme hat, findet hoffentlich diesen Beitrag ;)

# 
Monday, 07 May 2012

Achtung Sicherheitsproblem: PHP Quellcode u. U. im Browser lesbar

Ein Albtraum wird wahr: Wie ich gerade beim Boesenseo gelesen habe, besteht bei PHP-Scripten unter gewissen Bedingungen (PHP im CGI-Modus) eine realistische Chance, dass durch das simple Anhängen des Kommandozeilenparameters "-s" der Quellcode jeder PHP-Seite sichtbar gemacht werden kann... weitere Schweinereien per Kommandozeile sind freilich mit ausreichender krimineller Energie auch denkbar.

Man könnte diese Chance jetzt nutzen, um (mal wieder) dazu aufzurufen, alle kritischen Inhalte wie Zugangsdaten etc. auch in Kleinstprojekten und einfachen Scripts zum Mailversand etc. aus den erreichbaren PHP-Dateien fern zu halten und per geschütztem Include vor Zugriffen zu schützen... aber wer würde es schon hören? Es muss also reichen, auf den o. a. Beitrag zu verweisen und jedem Betreiber einer eigenen Site zu raten, den Schnelltest zu machen, indem z. B. die Startseite (nennen wir sie mal ganz willkürlich "index.php") mit dem Parameter -s (also "index.php?-s") aufgerufen wird. Sieht man nun den Quellcode, ist es höchste Zeit, sich an den Admin des Servers, den Hoster - oder wer auch immer für das Schließen dieser Lücke verantwortlich ist - zu wenden.

# 
Wednesday, 04 February 2009

phpBB: Wenn Google Analytics keine Daten bekommt

Das kommt davon, wenn man nicht gleich nachsieht: Vor Wochen habe ich in ein Projekt, welches mit phpBB betrieben wird, über die Templates einen Tracking-Code für Google Analytics implementiert und wollte nun erstmals nachsehen, wie es denn mit den Besucherzahlen dort aussieht und ob bestimmte Bereiche vielleicht mehr Aufmerksamkeit benötigen. Mein erstaunen war groß, als Google Analytics mir meldete, dass der Code korrekt implementiert sei, aber dennoch keine Daten gemessen wurden. "Warte auf Daten"... und zwar seit Wochen. Die Implementierung des Trackingcodes für Google Analytics in phpBB funktionierte also offenbar nicht.

Na klar! Der Code ist irgendwie nicht richtig implementiert. Aber warum? Die Lösung: phpBB scheint "Unnützes" bei der Ausgabe zu filtern und der Trackingcode von Google Analytics hat unter diesem Filter zu leiden. Ich muss gestehen, dass ich kein ausgewiesener phpBB-Fachmann bin und nur so eben gut genug zurecht komme, um ein Forum damit aufzusetzen und einige Anpassungen am Design zu erstellen. Daher habe ich auch keine Ahnung, ob dieses Verhalten per Option steuerbar ist oder nicht. Und so musste in meinem Fall eine eher triviale Lösung her: Ich habe ein Leerzeichen an passender Stelle eingefügt, danach wurden die Daten auch korrekt an Google Analytics übertragen. Falls sich jemand mit einem ähnlichen Problem rumschlagen sollte und dank Suchmaschine auf diesen Beitrag gestoßen ist - hier die Anleitung, damit das Tracking über Google Analytics korrekt funktioniert. 

Im Template lässt sich der Code - egal ob neuer oder alter Trackingcode -, welcher gern am Ende einer Seite wohnt und so möglichst wenig den Seitenaufbau verzögert, simpel - und vor allem korrekt und vollständig - z. B. in overall_footer implementieren. Hierin ist in der letzten Zeile des Trackingscripts ein leerer Anweisungsblock zur Fehlerbehandlung vorhanden. 

Code in phpBB einbauen

Wird diese Änderung gespeichert, liefert phpBB eine "optimierte Fassung" des Codes aus, in dem der leere Anweisungsblock leider fehlt. Dies sorgt dafür, dass das ganze Script nicht korrekt arbeitet und keine Daten bei Google Analytics ankommen. Im Quelltext einer produzierten fertigen Seite sieht das dann so aus:

Defekter Code im Quelltext

Um das Problem zu beheben, kann zwischen die beiden Klammern des leeren Anweisungsblocks im Script beim Einbau in das Template einfach ein Leerzeichen eingefügt werden. Dies reicht offensichtlich, um den Block nicht als "leer und verzichtbar" zu erkennen. Eine Seite beinhaltet nach dieser Anpassung dann auch den vollständigen Code.

Funktionierender Code

Analytics ist damit zufrieden und zeigt künftig Daten an. Die Lösung ist zwar vielleicht nicht elegant, funktioniert aber. Wer weiß, warum das Script ohne diese Anpassung "kaputtoptimiert" wird und wie man dies durch eine entsprechende Einstellung oder Option im System verhindern kann, dem wäre ich für einen entsprechenden Hinweis per Kommentar höchst dankbar.

# 
Monday, 03 November 2008

Delphi for PHP 2.0 für Nicht-Delphianer

Nach meinen eigenen Gehversuchen in Version 1 und einem nur virtuellen Überblick über Version 2.0 von Delphi for PHP hatte ich vergangene Woche im Rahmen der fragwürdigen "EKON 12 / Ajax In Action / International PHP Conference - Kombiveranstaltung" (dazu vielleicht später einmal mehr) die Gelegenheit, mir die nachgebesserte Fassung ein wenig näher anzusehen. Man muss schon zugeben, dass die Version deutlich besser als Version 1 dasteht. Und damit ist nicht nur die Hilfe gemeint, denn da war erstens noch reichlich Luft nach oben vorhanden und zweitens ist die Hilfe auch heute - in guter Delphi - Manier - immer noch nicht als Referenzklasse zu bezeichnen. Die allgemeine "Benutzbarkeit" hat aber merklich zugenommen und es ist für mich zumindest denkbar, dass man damit gute Ergebnisse erzielen kann (wenngleich ein Ernst zu nehmender kommerzieller Erfolg des Produkts nach wie vor unwahrscheinlich bleibt). Ich habe es nur mangels Not nie selbst ausprobiert.

Nicht zum ersten Mal habe ich mich aber gefragt, wer genau die Zielgruppe von Delphi for PHP ist. Streng genommen richtet sich Delphi for PHP ja nicht an Delphi-Anwender. Der Name soll zwar dazu dienen zu verdeutlichen, dass damit die Entwicklung von PHP-Anwendungen so einfach wie das Entwickeln in Delphi ist. Vor allem für Einsteiger ist Delphi for PHP schließlich ein prima Werkzeug.... die haben aber leider wahrscheinlich überhaupt keine Ahnung, was Delphi ist oder warum es toll sein sollte. PHP-Einsteigern und "Webentwicklungs-Umsteigern" ist es ganz bestimmt eine enorme Erleichterung, sich möglichst viel Arbeit von einer guten IDE und einem geeigneten Framework abnehmen zu lassen und sich im Idealfall nie mit Dingen befassen zu müssen, die "unter der Haube" stattfinden. Und Delphi for PHP bietet dem Entwickler in der Tat einige Vorteile:

  • Reichlich Wiederverwendbares in Form einer Framework- / Widget-  Kombination (VCL for PHP)
  • Effizientes lokales Entwickeln und Testen direkt nach der Installation
  • Die konfigurationsstressfreie Verwendung eines Debuggers
  • Die vergleichslose Integration eines Frameworks und einer IDE in Form der VCL for PHP und der produktivitätsfördernden Funktionalität einer Delphi-IDE; beides mehr oder weniger aus einer Hand (Quadram)
  • Ein brauchbarer Profiler, der bei der Optimierung von Performanceengpässen hilft
  • Der nahezu "codefreie" Einsatz von AJAX-Funktionalität dank der guten XAJAX-Integration
  • Zugriff (via adodb) auf zahlreiche Datenquellen ohne besonderen Konfigurationsaufwand

Wer also schon seine Wahl getroffen hat, bestimmte Frameworks kennen und lieben gelernt hat und auch mit seinem Editor hoch zufrieden ist, für den mag der Anreiz nicht groß genug sein; zumal man sich den Großteil davon selbst "herbeikonfigurieren" kann. Um aber nicht den typischen Einstieg über Bücher mit Scripten aus dem PHP3-Zeitalter zu machen und sich erst später mit Objekten, Frameworks und anderen Dingen jenseits von echo "Hallo Welt"; zu befassen, ist Delphi for PHP ganz sicher ein viel besserer Einstieg in PHP. Schade nur, dass wahrscheinlich wenige - mangels Kenntnis - diesen Weg wählen werden.

Klar, Delphi for PHP ist natürlich auch weit entfernt davon, perfekt zu sein und viele Funktionen wecken mehr Wünsche als sie zu decken, aber man muss ganz einfach anerkennen, dass hier eigentlich etwas sehr Richtiges getan wurde, indem man rund um PHP ein Gesamtpaket geschnürt hat, das dem Interessenten einen Einstieg erlaubt, ohne dass zuerst WAMPP / XAMPP, ein Editor, ein Framework, ein dies und ein jenes besorgt, installiert, konfiguriert und ausprobiert werden muss. Und vor allem steht hier das schnelle Ergebnis und eine gut bedienbare Benutzeroberfläche des Endprodukts - eben delphilike - im Vordergrund. Mit etwas mehr begleitender Literatur könnte dieses Paket vielleicht sogar noch attraktiver sein. Aber vielleicht macht MS es ja bald besser. Die Annäherung von Microsoft (in Form von Visual Studio, IIS & Co.) an PHP ist jedenfalls nicht mehr zu übersehen.

# 
Friday, 18 January 2008

PHP (und MySQL) unter Windows installieren

Viele Webmaster sind wohl eher der Meinung, die Begriffskombination "Windows-Server" ist allein schon ein Widerspruch, wenn es um eine geeignete Heimat für eine Internet-Domain ist. Und auch die Meinung, der Betrieb von PHP unter Windows sei so notwendig wie ein Macintosh-Emulator für Mobiltelefone, ist populär.

Wer sich aber dennoch mit der Installation und Inbetriebnahme von PHP und MySQL auf einem Windows-Server auseinandersetzen will, darf oder muss, ist für eine kurze, unzweideutige und hilfreiche Anleitung sicher dankbar. Empfehlenswert ist die Installationsanleitung für PHP unter Windows von ZDnet, denn sie erfüllt alle genannten Anforderungen an einen gute gute Anleitung.

Wer nach Abarbeitung erfolgreich ein phpinfo() ausgeführt hat, muss nur noch in der php.ini die gewünschten Einstellungen vornehmen und schon kann es losgehen.

Tipp: Die Einstellung "SMTP = localhost" für den Mailversand in der PHP.INI unter [mail function] lenkt die per mail()-Funktion versendeten Nachrichten in den meisten Fällen in´s Nirvana, also lieber gleich "SMTP = 127.0.0.1" dort eintragen.

# 
Saturday, 12 May 2007

Probleme beim Senden von Dateien per PHP

Sollte sich irgendjemand (außer mir Depp) mal fragen, warum es - in meinem Fall "plötzlich", nachdem es gerade noch vor der letzten Änderung ging - nicht mehr korrekt gelingt, eine Datei per PHP zu senden, obwohl der "gewollte Header" eigentlich prima aussieht, sollte mal nach Leerzeichen / Leerzeilen vor (und nach) dem PHP-Code suchen.

Dummerweise reicht ein einziges Leerzeichen vor dem einführenden "<?php" vollkommen aus, um die ganze Nummer zu versauen und einen text/html-Content zu generieren - egal, was der PHP-Code danach versucht, so dass die Datei nicht wie gewünscht gesendet, sondern statt dessen - je nach Dateityp mehr oder weniger sinnvoll - im Browser dargestellt wird.

<?php
//da oben steht es, das blöde Leerzeichen! Weg damit, schon klappt´s!
$userfile = "pfad/meine_lustige_datei.zip" ;
header("Content-Type: application/octet-stream") ;
header("Content-Length: " .(string)(filesize($userfile)) ) ;
header('Content-Disposition: attachment; filename="'.basename($userfile).'"') ;
header("Content-Transfer-Encoding: binary\n") ;
readfile($userfile) ;
?>

Also: Wenn ein ansonsten gut funktionierender Code wie dieser Folgende hier nicht in der Lage ist, eine Datei wie gewünscht zu senden, sondern diese im Browser anzeigt, mal besonders die erste Zeile nach führenden Leerzeichen durchsuchen. Spart ggf. viel Zeit, die ich heute durch sinnloses "Debugging auf gut Glück" verbraten habe :(

#