Nachdem meine Evaluationszeit bei TextMate abgelaufen war musste ich mich nach einem neuen Editor für kleine Arbeiten umsehen (ansonsten kommt bei mir als IDE Netbeans zum Einsatz u.a. für die Entwicklung meiner WordPress Plugins). Eine wichtige Aufgabe ist z.B. die Möglichkeit schnell ein Skript/eine Konfigurationsdatei auf einem Server zu Bearbeiten (insbesondere im Zusammenspiel mit Cyberduck) und natürlich Syntax-Highlighting. In die engere Auswahl kamen Komodo Edit (Open Komodo) und TextWrangler.

» weiterlesen…

Aufgrund einer XSS-Lücke gibt es nun ein weiteres Update für den 2.8er Zweig von WordPress. Desweiteren wurde auch gleich noch ein Bug der im Zusammenhang mit einer bestimmten Konfiguration des Indianers auftaucht gefixed.

Bei mir verlief das Update – wie immer – problemlos

[Update]Wie ich gerade bei Golem.de gelesen hab, lassen sich beider Lücken nur als angemeldeter Benutzer ausnutzen. Nichtsdestotrotz ist ein Update (auch ohne offene Benutzerregistrierung) empfohlen.[/Update]

Gefunden bei: Blogprojekt.de

Bei meinem AdServer haben sich im Laufe der Zeit größere Mengen an Statistiken angesammelt, die eigentlich nicht mehr benötigt werden (ich schau sie mir nicht mehr an und sonst hat derzeit Niemand zugriff darauf). Aber wie wird man die alten Statistiken los? Eine Funktion dafür gibts in OpenX leider nicht und im Forum gibts nur ein paar Anmerkungen, wie “lösch halt die Tabellen mit _data_”. Im Internet bin ich dann über diesen Blogbeitrag “Purge OpenX statistics tables” gestolpert und im Grunde ist es also auch gar nicht so schwer (unverständlich, warum man das nicht im Backend direkt machen kann).

Sprich, wer wie ich alle Daten die älter als 3 Monate sind, kann auf eigene Gefahr folgendes probieren:
DELETE FROM ox_data_intermediate_ad WHERE interval_end < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);
DELETE FROM ox_data_summary_ad_hourly WHERE date_time < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);
DELETE FROM ox_data_summary_zone_impression_history WHERE interval_end < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);

Irgendwie hatte ich schon länger mit den Hooks für wp_enqueue_style bzw. wp_enqueue_script herumexperimentiert, um die dort in die Warteschlange gestellten CSS- bzw. JavaScript-Dateien abzufangen und mit Hilfe von minify verkleinert auszugeben.

Sicherlich gibt es dafür schon ein fertiges Plugin, nur gefällt mir Methode von WP Minify die CSS- bzw. JavaScript-Dateien via regulärer Ausdrücke herauszufiltern irgendwie nicht so ganz und so habe ich nun eine erste (und zumindest für CSS-Dateien) lauffähige Version hier im Blog im Einsatz, die auf die Warteschlange zurückgreift. Wenn die weiteren Tests im produktiven Einsatz erfolgreich verlaufen, ich noch den einen oder anderen “Bug” eliminiert habe und das Ganze auch noch für JavaScript-Dateien funktioniert, gibts vll. bald einen Patch für WP Minify oder ein neues Plugin von mir. Wobei, insgesamt bin ich auch von meiner Methode noch nicht so ganz überzeugt…

Ergebnis in meinem Blog: Statt 7 nur noch eine CSS-Datei, und auch die Größe ist von 34,6KB auf 18,5KB gesunken.

Die neue Version von WordPress (2.8 – Baker) enhält u.a. einige Verbesserungen bzgl. der Widgets (drag’n drop + mehrfache Verwendung) sowie die Installation/Update von Themes direkt aus dem Adminbereich (wie bei den Plugins). Insgesamt soll sich mit dem neuen Release auch die Geschwindigkeit verbessert haben. Insgesamt wurden wohl rund 790 Fehler beseitigt.

Das Update hier im Blog verlief problemlos (zumindest ist mir noch nichts aufgefallen) und auch meine Plugins (Floatbox Plus, Gallery Widget, hype it!, TinyCode) scheinen mit WordPress 2.8 kompatibel zu sein. Sofern sich in den nächsten Tagen keine Fehler zeigen, werde ich die Plugins auch offiziell als 2.8 tauglich einstufen, sprich die Beschreibung dahingehend anpassen.

Seit heute ist das neue iX-Sonderheft “Web on Rails” im Zeitschriftenhandel. Themenschwerpunkt des Sonderhefts sind, wie der Titel mit seiner Anspielung auf Ruby on Rails schon andeutet, Frameworks für die Webentwicklung (ASP.Net, Java, Perl, PHP, Python, Ruby und Smalltalk).

Ich empfehle insbesondere den Artikel “Sechs PHP-Template-Engines” ab Seite 12

Nachdem ich die Tage mal wieder ein vBulletin updaten durfte (3.6.x -> 3.8.1) bin ich auch unweigerlich auf das Problem gestossen, dass das eine oder andere Addons keine Lust mehr hatte mit der neuen Version zusammenzuarbeiten. Daraus resultierend hatte ich auch kein Bock mehr und hab einfach alle bisherigen Addons rausgeschmissen und von vorne angefangen. Bei meiner Suche nach neuen (oder auch “alten”) Addons bin ich u.a. über folgende gestolpert:

Infobar On All Pages: Hier lässt sich ein kleiner Hinweis am oberen Rand anzeigen (ähnlich wie die Meldungen beim Internet Explorer) um z.B. die noch nicht registrierten Besucher aufzufordern dies doch vll. zu tun (derzeit kann man 2 Meldungen hinterlegen)

Cyb – Advanced Forum Statistics: Die Statistiken stehen für mich eher im Hintergrund, vielmehr die Anzeige der neusten Beiträge stand für mich bei diesem Addon schon immer im Vordergrund. Nichtsdestotrotz ist für viele Benutzer z.B. die Anzeige der TopPoster ein wichtiger Punkt…

Usergroup Color Bar Legend: Für mich auch eine unverzichtbare Erweiterung, damit weiss man sofort (anhand der Farbe des Benutzernamens) mit wem man es zu tun hat, denn bei der “Wer ist online”-Liste wird damit eine kleine Legende angezeigt.

Display Unread Posts and New Reputation Comments: Diese Erweiterung zeigt im persönlichen Infoblock die Anzahl der ungelesenen Beiträge und neuerdings auch der “Ansehens”-Kommentare an (natürlich inkl. Link zur jeweiligen Übersicht).

vbAnonymizer: Unterdrückt “deeplink”-Referrer, sprich alle ausgehenden Links bekommen als Referrer-URL die Basisadresse.

Dies waren erstmal eher die kleinen Plugins für die Frontendseite/den Besucher. Die Tage werde ich dann noch den für mich unverzichtbaren kleinen Helferleins für den Admin bzw. den grösseren Addons (die tiefer ins System eingreifen) einen Beitrag widmen…

Die Tage hatte ich mich wiedereinmal mit der Optimierung der “Render”-Geschwindigkeit von WordPress beschäftigt und musste schnell feststellen, dass die einfache Anzeige der Zeit + Anzahl der SQL-Queries nicht wirklich das Optimum ist. Lässt sich z.B. mit folgendem Code direkt im Template umsetzen (wird nur bei nem Userlevel > 5 angezeigt):

<?php global $userdata;
get_currentuserinfo();

?>
<?php if ($userdata->user_level > 5) { ?>( <?php echo $wpdb->num_queries; ?>q, <?php timer_stop(1); ?>s ) <?php } ?>

Aber wie schon gesagt, man sieht hier nur einen allgemeinen Trend, nicht aber welcher Teil von WordPress (z.B. welches Plugin) denn z.B. eine Bremse ist. Einen ersten Ansatz liefert z.B. das Plugin Debug-Queries von bueltge.de, noch umfangreicher und leichter zu konfigurieren gibt es das Ganze als WordPress Plugin “WP Tuner“. Das Plugin ist damit insbesondere für Entwickler eine absolute Empfehlung. Die angezeigten Ergebnisse sind unterteilt in eine Geschwindigkeitsanalyse (unterteilt in: Seitengenerierungsgeschwindigkeit, Plugin/Theme-SQL-Geschwindigeit und SQL-Tabellengeschwindigkeit) und die SQL-Abfragenanalyse (Geschwindigkeit/”EXPLAIN”). Wer selbst noch etwas Hand an WordPress anlegt, kann noch weitere “Hooks” zur Geschwindigkeitsanalyse hinzufügen.

Und noch ein Update für mein WordPress Plugin “Gallery Widget“, das letzte für dieses Jahr.

Neu mit dabei ist die Option “nur ein Bild pro Beitrag”. Die Option funktioniert allerdings nur bei der Option “include/exclude” und kann auch direkt via PHP-Funktion genutzt werden. Wie der Name schon andeutet, gibt es nun die Möglichkeit nur ein Bild pro Beitrag anzuzeigen, falls bei einem Beitrag mehrere Bilder vorhanden sind…

Ansonsten gilt, wie immer: Wer Bugs findet, oder ein Feature wünscht, möge sich bitte im TicketSystem/Wiki äussern.

PHP wird ja gerne als Skriptsprache für Kiddies abgestempelt (darüber zu diskutieren lohnt nicht!). Was vielen eher unbekannt ist, es gibt schon länger einen Compiler: Roadsend PHP. Roadsend PHP ist eine quelloffene und eigenständige (basiert nicht auf der ZendEngine) Implementierung der (Skript-)Sprache PHP und ermöglicht es eigenständig lauffähige Programme zu erzeugen (Binaries, es wird zur Laufzeit kein Interpreter mehr benötigt). Es werden weite Teile von PHP4/5, sowie einige Erweiterungen unterstützt. Aktuell findet ein Rewrite unter C++/LLVM statt.

Neu (wobei es das Konzept dazu auch schon eine Weile gibt) ist phc. Hier wird der PHP-Code in C-Code übersetzt und dann durch den GCC gejagt. Das Ergebnis ist auch hier ein natives Binary. Zusätzlich lässt sich mit phc der Sourcecode auch zum Einen “aufhübschen” (pretty-print) bzw. zum Anderen unleserlich machen (obfuscate).

Der Vorteil?

Nun, zum Einem muss man den Sourcecode bei einem kleinen Kommandozeilen-Skript nicht mehr herausgeben und ist auch nicht mehr auf die Installation des Interpreters angewiesen (mir ist durchaus bekannt, das es für PHP entsprechende Encoder gibt, doch deren Byte-Code/Zwischencode lässt sich deutlich leichter “entschlüsseln”).

Zum Anderen lassen sich damit z.B. eigene Bibliotheken/Extensions schreiben und damit Performancegewinne zur Laufzeit realisieren. Sicherlich sind diese Extensions nicht das Mass der Dinge, und mit Handarbeit (am C-Code) dürfte sich noch einiges an zusätzlicher Perfomance gewinnen lassen, aber für den “einfachen” PHP-Entwickler dürfte dies ein einfacher Einstieg in die Extensions-Entwicklung sein.