PHPGangsta - Der praktische PHP Blog

Da PHP 5.6 vor der Tür steht (die Beta müßte jeden Tag erscheinen, und die finale Version dann in einigen wenigen Wochen) fragte ich mich wie es mit der PHP 5.5 Verbreitung aussieht, immerhin ist 5.5 bereits am 20. Juni 2013 veröffentlich worden, also vor fast 10 Monaten. Bei mail.de sind wir erst Anfang Februar auf 5.5 umgestiegen, wir nutzen keine Software im Produktivbetrieb kurz nachdem sie released wurde und warten immer ein paar Wochen ab bis die ersten Bugfix-Releases erschienen sind. Wenn Zeit da ist versucht man sich bereits vorher an einer Testumgebung, aber diesmal fehlte die Zeit dies ausführlich machen zu können Mitte des Jahres. Ende des Jahres hatten wir so viel um die Ohren sodass wir erst Anfang dieses Jahres dazu gekommen sind.

Je größer die Umgebung, je umfangreicher die Applikationen und je mehr unterschiedliche Projekte mit externen Abhängigkeiten man hat, desto aufwändiger sind die Tests und die Änderungen die man machen muss. Mit der Version 5.5 gab es kaum Änderungen an Funktionen um die man sich kümmern muss wie man im Migration Guide 5.5 lesen kann. Wichtig sind vor allem die Backward Incompatible Changes, die Deprecated Features und die Changed Functions. Für uns jedoch war die wichtigste Änderung die Einführung des OpCache, der ehemals als Zend Optimizer+ bekannte Bytecode-Cache der nun mit PHP ausgeliefert wird. Wir nutzten bis dahin seit Jahren APC als Bytecode-Cache und auch als lokalen Usercache. Nun wechseln wir weg von APC hin zu OpCache und APCu. Da wir dort die meisten Probleme erwarteten mußten wir dies besonders gut testen, denn in den letzten Monaten sind noch einige kleine Bugs in APCu aufgetreten.

Weiterlesen »

Heute eine kleine Umfrage. Es ist anonym und keiner muss sich rechtfertigen (kann aber natürlich gern in den Kommentaren, die Gründe sind sicher interessant!).

Es geht um die ext/mysql Extension, sprich die mysql_* Funktionen. In PHP 5.5 wurden sie DEPRECATED, d.h. es gibt eine Deprecation-Warnung im PHP-Error-Log dass die Funktionen nicht mehr benutzt werden sollen da sie bald entfernt werden.

Nun stehen die Planungen für PHP 5.6 an, und eine Frage ist: Soll ext/mysql entfernt werden, nachdem es in der letzten Version als veraltet markiert wurde? Entfernen heißt in diesem Zusammenhang: Verschieben aus dem Kern in die PECL Library. Wer es unbedingt noch braucht kann es also separat nachinstallieren. Im englischen PHP-Online-Manual gibt es große rote Warnungen dass es nicht mehr genutzt werden sollte, in der deutschen Variante aber leider nicht.

Hier also meine kleine Umfrage:

 Wird geladen ...

Ich selbst habe aktuell ein kleines Kommandozeilenscript das ich umschreiben muss, und WordPress nutzt es noch, ansonsten bin ich Dank dem Zend Framework, welches PDO nutzt, glaube ich ext/mysql-frei.

Gastartikel von Oliver Sperke.

Ich bin 35 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.

Nach langem Arbeiten an einem Projekt fängt der ambitionierte Entwickler an, zu testen, wie sich seine dynamische Internetseite unter Last verhält. Da ja jeder von uns von Millionen Besuchern träumt, will man natürlich auch wissen, wie sich Millionen von Besucher anfühlen und ob unser „kleines Kunstwerk“ davon genau so begeistert wäre wie wir. Dynamische Webseiten sind toll, allerdings hat der gemeine Internetserver ein großes Problem damit. Die Erzeugung ist meist sehr aufwendig. Daten müssen aus Datenbanken geholt werden, Berechnungen wollen berechnet werden und Blogeinträge müssen wie Blogeinträge aussehen.

Seit Jahren hat sich eine simple Technik etabliert, die diese gequälten Webserver entlastet. Jeder fortgeschrittene Entwickler kennt und liebt sie, weil sie so schön einfach und universal einsetzbar ist: *trommelwirbel* Das Caching *tusch*. Da aber Caching an sich ein uralter Hut ist, will ich Euch zeigen, wie Ihr evtl. Eure Performance mit minimalen Änderungen mehr als verdoppeln könnt.

Am Anfang war der Benchmark

Weiterlesen »

Letzten Donnerstag Abend habe ich mich mal wieder etwas um meine WordPress-Plugins gekümmert. Zwei wollten upgedated werden, eins habe ich ersetzt und auch ein neues installiert.

Das neue Plugin Smart Archives Reloaded erstellt eine coole Archiv-Seite, auf der alle Artikel nach Jahren und Monaten sortiert aufgelistet sind, und man so schnell die Artikel eines bestimmten Zeitraums finden kann. Es gibt vier Einstellungsmöglichkeiten bei der Präsentation der Liste, ich habe die Javascript-Variante genommen damit die Liste nicht so ewig lang wird, und sie ist auch die coolste von allen 😉

Das Plugin Subscribe To Comments habe ich ausgetauscht gegen das neuere Subscribe To Comments Reloaded. Endlich ist es möglich ein Double-Opt-In Verfahren zu aktivieren, und auch das Management-Werkzeug im Admin-Bereich ist viel cooler, man kann viel mehr Dinge einstellen, Texte ändern und auch die Abonnements administrieren. Für die Benutzer gibt es nun die Möglichkeit sich benachrichtigen zu lassen ohne einen Kommentar hinterlassen zu müssen, finde ich auch super. Des weiteren ist die Administrierbarkeit des Benutzers schöner geworden.

Weiterlesen »

So, nun habe ich etwas Zeit gehabt und auf die suchmaschinenfreundliche URL-Struktur umgestellt. Vorher hatte ich umgestellt auf /%post_id% , sodass Artikel unter
https://www.phpgangsta.de/630
verfügbar waren. Das war primär dafür gemacht, dass ich diese kurzen URLs in Twitter nutzen kann, da ich Short-URL-Dienste hasse (man weiß nie was dahinter versteckt ist).

Nun habe ich die Struktur umgestellt auf /%postname% , sodass der selbe Artikel nun standardmäßig so verlinkt ist:

Taugt Zend_Queue etwas?

ABER: Da ich die kurzen URLs nicht verlieren wollte (und die Links in Google/Twitter weiterhin funktionieren sollen) habe ich meine .htaccess noch angepasst, sodass ich nun beide Formate nutzen kann. In Twitter kann ich also weiterhin meine geliebten Kurz-URLs nutzen, im Blog wird allerdings der Postname genutzt. Meine .htaccess sieht nun so aus:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^([0-9]+)$ /?p=$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Falls also in der URL nur Zahlen vorkommen, sende ich einen „301 Permanent Redirect“ auf die URL ?p=<id> , diese URL wandelt WordPress dann nochmals um und leitet auf die URL mit dem Postnamen um. In Google sollten nun also bald die Artikel nur noch mit dem Postnamen erscheinen und die ID-URLs bald verschwinden. Ich bin gespannt, ob das so klappt.

Um nur einen 301 Redirect zu nutzen hätte ich ein kleines Script schreiben müssen, welches aus einer ID die Postname-URL herausfindet (Datenbank?) und dann redirected. Ob das einfach ist und vor allem bei zukünftigen WordPress-Updates noch funktioniert würde ich bezweifeln, und soweit ich weiß sind 2 Redirects kein Problem, oder hat jemand andere Informationen?

Jedenfalls funktioniert es nun so wie ich möchte, und Google werde ich in den nächsten Tagen mal beobachten.