{"id":551,"date":"2017-02-01T08:55:38","date_gmt":"2017-02-01T07:55:38","guid":{"rendered":"http:\/\/revue.local\/?post_type=dev&p=551"},"modified":"2017-02-01T08:58:11","modified_gmt":"2017-02-01T07:58:11","slug":"wordpress-fehlersuche","status":"publish","type":"dev","link":"https:\/\/revue.local\/dev\/wordpress-fehlersuche\/","title":{"rendered":"5 Stunden Fehlersuche? Krasser schei\u00df."},"content":{"rendered":"

Haben Sie schon einmal vom „WordPress White Screen of Death“ geh\u00f6rt? Zu deutsch etwa „wei\u00dfer Bildschirm des Todes“? Nat\u00fcrlich. Sie sind ja Entwickler und hatten dieses unsch\u00f6ne Problem sicher schon einmal. Wie fixt man es? Eine Vorgehensweise w\u00e4re, das Debugging \u00fcber die Debug-Konstanten in der wp-config.php zu aktivieren<\/a>. Oft bekommt man dann schon die Fehlermeldung auf dem Silbertablett serviert und man wei\u00df, welches Plugin hier eventuell rumzickt.<\/p>\n

Aber es gibt auch extreme Sonderf\u00e4lle. Was ist, wenn es keine PHP-Fehlermeldung gibt und die Seite trotzdem wei\u00df ist? Was, wenn die Seite manchmal wei\u00df ist und manchmal nicht? Puuh… schwierig? Sie sagen es. Und genau so einen Fall hatte ich vergangen Monat bei einem Kunden. Die verr\u00fcckte Story m\u00f6chte ich kurz mit Ihnen teilen. Mein Kunde antwortete mit dem Kommentar „krasser schei\u00df“<\/em> als ich ihm die Problematik schilderte, aber auch eine L\u00f6sung pr\u00e4sentieren konnte.<\/p>\n

<\/a>WordPress Fehlersuche = Reengineering?<\/h2>\n

Einer meiner Kunden machte ein Update von CometCache (ein WordPress-Cache-Plugin). Dann wurden pl\u00f6tzlich einige Seiten nicht mehr richtig zwischengespeichert. Das hei\u00dft, einige Seiten waren wei\u00df, andere wiederum nicht. Eine Systematik konnte man nicht erkennen. Wir wussten aber, dass es an diesem Plugin lag. Denn wenn es deaktiviert wurde, funktionierte alles. Was unternimmt man in so einem Fall?<\/p>\n

    \n
  1. Zuerst habe ich gepr\u00fcft, ob PHP einen Fehler wirft. Die Antwort: nein.<\/li>\n
  2. Danach pr\u00fcfte ich das Plugin lokal und in einer Staging-Umgebung. Hier hat es funktioniert. Das Problem besteht also nur auf dem Live-System.<\/li>\n
  3. Also machte ich eine 1-zu-1 Kopie des Produktivsystems auf das Staging. Ahja und siehe da: hier konnte ich das Problem reproduzieren. Ich wusste allerdings immer noch nicht, woran es lag. Sporadisch waren manche Seiten wei\u00df.<\/li>\n
  4. Also deaktivierte ich alle Plugins. Das Problem bestand immer noch.<\/li>\n
  5. Also deaktivierte ich auch das Theme. Hier funktionierte das Caching. Lag es am Theme?<\/li>\n
  6. Danach begann ich mit den Einstellungen des Cache-Plugins zu spielen und da habe ich gemerkt, dass die HTML-Kompression die Ursache war. Nun war die Fragestellung eine andere: Warum hatte der Kompressor Probleme mit manchen Seiten und mit manchen nicht? Und was hatte das Theme damit zu tun?<\/strong><\/li>\n
  7. Also suchte ich mir im Code von Comet-Cache die Stelle an der die HTML-Kompression durchgef\u00fchrt wurde. Da bemerkte ich, dass die Entwickler mit preg_replace_callback()<\/a> eine Ersetzung vornehmen. Die hat zwar eigentlich nichts mit dem Code an sich zu tun, aber interessanterweise gab es – im Vergleich zur vorherigen Version – eine kleine Anpassung. Und zwar die Erweiterung des regul\u00e4ren Ausdrucks um den u-Modifizierer<\/a>.<\/li>\n
  8. Also habe ich nachgeschaut was denn dieser Modifizierer eigentlich tut: Aha! Zwei Dinge: Er schaltet die PCRE-Funktionalit\u00e4t ein und die zu untersuchende Zeichenkette wird als UTF-8 behandelt. Mein Gef\u00fchl sagte mir, dass es also ein UTF-8 Problem war. Denn wenn dieser Modifizierer entfernt wurde, funktionierte wieder alles problemlos. Die neue Fragestellung war also: wo im Code des Themes gibt es ein UTF-8 Problem?<\/strong><\/li>\n
  9. Also begann ich mit dem ausschlie\u00dfen des Codes bis ich den entsprechenden Teil gefunden hatte.<\/li>\n
  10. Am Ende kam ich bei den Social-Media-Links an. Dort gibt es n\u00e4mlich einen Link, der es erlaubt, eine Seite per E-Mail zu teilen (<a href=\"mailto:?subject=Beitragsname\">[Mail-Icon]<\/a><\/code>).<\/li>\n
  11. Wir \u00fcbergeben als Betreff den Beitragsnamen. Und die Titel der Beitr\u00e4ge haben in der Regel auch Leerzeichen. Um das zu umgehen, kann man sich der Funktion antispambot()<\/a> bedienen. Sie sorgt daf\u00fcr, dass E-Mail-Adressen f\u00fcr Bots schwerer zu lesen sind und man kann auch besondere Dinge (wie Leerzeichen) nutzen.<\/li>\n
  12. Beispiel: Der Tag <a href=\"mailto:?subject=Ein interessanter Artikel\">[Mail-Icon]<\/a><\/code> w\u00fcrde zu <a href=\"mailto:?subject=Ei&#110; i&#110;&#116;e&#114;e&#115;san&#116;e&#114;&#32;Ar&#116;ik&#101;l\">[Mail-Icon]<\/a><\/code> werden.<\/li>\n
  13. Problem gel\u00f6st? Leider nein, denn ich wusste nicht, warum der Kompressor nur auf manchen Seiten Probleme hatte und auf manchen nicht. Die Fragestellung war also: Warum nur auf manchen Seiten?<\/strong><\/li>\n
  14. Und die Antwort war dann folgende: Manche Beitr\u00e4ge hatten Umlaute im Titel. Und genau die waren am Ende das Problem zusammen mit der Umwandlung durch antispambot() und des HTML-Kompressors.<\/strong><\/li>\n
  15. Ich habe ein Issue-Ticket auf Github erstellt<\/a> und die Entwickler gefragt, ob sie die Problematik reproduzieren k\u00f6nnen. Bislang jedoch ohne Erfolg. Meines Wissens besteht das Problem auch, wenn man Umlaute in die zu \u00fcbergebende E-Mail-Adresse einf\u00fcgt (es muss also nicht unbedingt der subject-Parameter \u00fcbergeben werden, um den Fehler zu erzeugen).<\/li>\n
  16. Die endg\u00fcltige L\u00f6sung f\u00fcr uns? Das Umgehen von Umlauten im Titel und das Anwenden von remove_accents()<\/a>.<\/li>\n
  17. Ich wollte dann nicht weiter nachforschen. Meine Vermutung war ein UTF-8-Fehler. L\u00e4sst sich das ausschlie\u00dfen? Ich wei\u00df es nicht, denn die Umwandlung durch antispambot() hat nichts mit UTF-8 zu tun. Hat der Kompressor ein Problem mit Umlauten? Das m\u00fcssen die Entwickler pr\u00fcfen.<\/li>\n<\/ol>\n

    Krasser schei\u00df? Richtig. Unabh\u00e4ngig von der Problematik sieht man mal wieder, dass Fehler ganz anderer Natur sein k\u00f6nnten als urspr\u00fcnglich gedacht. Und: Problemsuchen sind extrem Zeitintensiv. Aber man muss sie l\u00f6sen sonst kommt man nicht mehr weiter.<\/p>\n

    \n

    Freiberuflich auf Kundenfang?<\/h2>\n

    Sind Sie freiberuflicher Entwickler? Wenn ja, sind Sie sicherlich auch immer auf Kundenfang. Zwar sind die Zeiten aktuell gut (jeder braucht irgendwie einen Entwickler) aber wie kommt man eigentlich an die guten Kunden und wie kann man mit diesen perfekt verhandeln?<\/p>\n

    Am Ende m\u00fcssen wir nicht nur entwickeln und designen k\u00f6nnen<\/a>. Nein, wir m\u00fcssen auch verkaufen k\u00f6nnen. Aber wie geht das? Da gibt’s ein paar Tricks und es sind keine Geheimnisse. Jeder kann es lernen. Und zwar einfach indem man ein Buch liest.<\/p>\n

    Ich hatte mir am Jahresanfang vorgenommen, mehr B\u00fccher zu lesen die ich eigentlich nicht gelesen h\u00e4tte, die aber doch zu meiner Arbeit passen. Ein Designer schlug mir dann das Design-Buch-f\u00fcr-Nicht-Designer<\/a> vor. Ein Verk\u00e4ufer hat mir nun ein zweites Buch vorschlagen welches ich guten Gewissens weiterempfehlen kann:<\/p>\n

    \"The<\/a>
    The Little Red Book of Selling<\/figcaption><\/figure>\n

    The Little Red Book of Selling<\/a> ist zwar schon etwas \u00e4lter (2004), hat aber von seiner Aktualit\u00e4t nichts verloren. Der Autor –\u00a0 Jeffrey H. Gitomer – schreibt locker und l\u00e4ssig wie man am besten verkauft.<\/p>\n

    Hier ein Beispiel: Was tun Sie wenn der Kunde zu Ihnen sagt, dass Ihre Dienstleistung zu teuer sei? Die richtige Herangehensweise w\u00e4re, dass man sich gar nicht rechtfertigt, sondern Fragen stellt. So etwas wie „Sind Sie auf der Suche nach dem besten Entwickler oder nach dem billigsten Angebot?“<\/em> w\u00e4re angebrachter. Und schon ist der Kunde in Zugzwang. Das das tats\u00e4chlich funktioniert, kann ich belegen. Ich hab’s n\u00e4mlich schon ein paar mal gebraucht.<\/p>\n

    Gitomer pr\u00e4sentiert in seinem englischsprachigen Buch 12 1\/2 Prinzipien denen man folgen soll. Wer nicht so sehr auf das Englische steht, dem lege ich Die Kunst des klugen Fragens<\/a> ans Herz. Es hat zwar nicht direkt einen Bezug zum Verkauf, geht aber in eine sehr \u00e4hnliche Richtung.<\/p>\n

    Nun lassen Sie uns aber zu den WordPress Entwickler-News kommen:<\/p>\n

    \n

    <\/a>WordPress Entwickler-News<\/h2>\n

    Es gab zwei Updates von WordPress im Januar. Version 4.7.1<\/a> schloss unter anderem eine Sicherheitsl\u00fccke im PHPMailer die erst vor kurzem bekannt wurde. Version 4.7.2<\/a> behob eine CSS-Vulnerability und eine SQL-Injection (engl.).<\/p>\n

    \n

    Durch einem Vorschlag von Felix Arntz k\u00f6nnte uns demn\u00e4chst eine \u00dcberarbeitung der Bulk\/Row-Actions bevorstehen<\/a>. Das ist die Funktion in der man mehrere Dinge einer Liste gleichzeitig bearbeiten kann (z.B. die Zuweisung von Benutzern zu einer Seite in der Multisite-Umgebung) (engl.).<\/p>\n

    \n

    Unit Testing. F\u00fcr viele von uns ein ungeschriebenes Blatt. Thorsten Frommen hat nun einen sehr detaillierten Blogpost ver\u00f6ffentlicht der Ihnen helfen k\u00f6nnte, in das Unit-Testing (mit WordPress)<\/a> einzusteigen (engl.).<\/p>\n

    \n

    Bei Torque gab es einen guten Artikel zum Thema Dependency Injection in WordPress<\/a> (engl.).<\/p>\n

    \n

    Im letzten Nicht-Entwickler-Newsletter<\/a> habe ich dar\u00fcber berichtet, dass Matt Mullenweg die Tech- und Design-Leads bekanntgegeben hat. Die Arbeit ist schon voll im Gange. Tammie Lister hat deswegen gleich mal in die Runde gefragt, wof\u00fcr und wie der Customizer bei den verschiedenen Usern zum Einsatz kommt (engl.).<\/a><\/p>\n

    \n

    Das Theme-Developer-Handbook wurde nach fast zwei Jahren endlich ver\u00f6ffentlicht (engl.).<\/a><\/p>\n

    \n

    Nicht vergessen: Das WordCamp Europe steht an.<\/a> Wer noch nie in Paris war sollte die Veranstaltung zum Anlass nehmen, sich auch die Stadt n\u00e4her anzuschauen. Das Camp findet zwischen dem 15. und 17. Juni statt. Es gibt nur noch knapp 60 Tickets!<\/p>\n

    \n

    Ende letzten Jahres habe ich angek\u00fcndigt<\/a>, mehr \u00fcber die etwas unbekannteren Funktionen in WordPress zu schreiben. Im aktuellen Blogpost auf postmeta.blog geht es um die Funktion wp_list_pluck()<\/a>.<\/p>\n

    \n

    <\/a>PHP-Entwicklung<\/h2>\n

    PHP 5.6. wird seit Januar nicht mehr weiterentwickelt.<\/a> Es gibt lediglich noch Sicherheitsupdates. Sie sollten ihre Kunden nun auf PHP7 umstellen.<\/p>\n

    \n

    Wie geht PHP intern eigentlich mit Variablen um?<\/a> Ein sehr interessanter (und verst\u00e4ndlicher) Artikel. Allerdings auf englisch.<\/p>\n

    \n

    Was ist eigentlich SRI, CSP, HPKP, HSTS?<\/a> T3N hat\u2019s erkl\u00e4rt (dt.).<\/p>\n

    \n

    Haben Sie sich auch schonmal dar\u00fcber ge\u00e4rgert, dass Firefox das Date-Input-Feld nicht unterst\u00fctzt hat?<\/a> Das \u00e4ndert sich wohl jetzt. Juhuu!<\/p>\n

    \n

    Google AMP ist B\u00f6se f\u00fcr das Open Web.<\/a> So l\u00e4sst sich der Blogpost von Code vs. The World zusammenfassen. Unter anderem, weil man sich zu sehr von Google abh\u00e4ngig macht (engl.).<\/p>\n

    \n

    Welchen Code-Editor nutzt ihr eigentlich? Das war die Frage von Zac Gordon an seine Twitter-Follower. Ca. 250 Entwickler haben teilgenommen. Hier das Ergebnis:<\/p>\n

    \n

    What code editor are you currently using the most?<\/p>\n

    — Zac Gordon (@zgordon) January 18, 2017<\/a><\/p><\/blockquote>\n