Beim letzten Update hatte sich leider ein Bug eingeschlichen und der Play-Button wurde an der falschen Stelle (ausserhalb des Vorschaubildes) angezeigt. Neben dem entsprechenden Bugfix, gibt es nun in den Einstellungen die Möglichkeit auszuwählen, ob der Play-Button als Bild oder in der Textvariante angezeigt werden soll. Die Textvariante erhielt zudem noch eine kleine Überarbeitung, sie wird nun auch mit einer leichten Transparenz angezeigt (sollte auch im Internet Explorer funktionieren).

» weiterlesen…

Heute möchte ich ein Plugin vorstellen, dessen Funktionialität eigentlich in den Core gehört: WPLANG Lite.

Im Grunde verrät der Name schon um was es geht, das Sprachfile. Doch was genau macht es? Einfach ein paar selten genutzte Sprachfetzen aussortieren? Naja, fast. Es stellt einfach ein separates Sprachfile (.mo) fürs Frontend zur Verfügung und erlaubt es einem so eine ganze Menge Speicher zu sparen. Wer braucht schon im Frontend alle Phrasen des Backends?

Bei mir im Blog hat es den Speicherverbrauch von vorher ca 33MB auf ca 27,75MB gesenkt und ich bin noch über keine fehlenden, nicht übersetzte Phrasen gestolpert. Wer noch weiteres Optimierungspotential sieht, der kann z.B. noch die geänderte mo.php aus diesem Beitrag verwenden.

Wer einen Fehler (“parse error on line 714″) beim Update bzw. beim Installieren von Floatbox Plus bzw. bei der Aktivierung bekommen hat, der möge Floatbox Plus einfach nochmal neuinstallieren (die Einstellungen gehen nicht verloren).

Der Fehler ist durch ein “kleines” Problem beim hochladen des Updates ins SVN von WordPress.org entstanden, durch einen Konflikt war schon die neue readme.txt hochgeladen, nicht aber die eigentliche Version. So wurde statt der neuen Version die Variante aus dem “trunk” verwendet, die buggy ist und leider war es mir nicht sofort möglich den Fehler zu beheben (ich synchronisiere ein lokales SVN via SVK mit dem SVN von WordPress.org, und beim mergen gab es einen Konflikt, der nicht direkt zu lösen war *grml*). Aber nun sollte wieder alles funktionieren.

Mit dem Update auf Version 1.0.0 erkläre ich GravatarLocalCache für stabil und für den produktiven Einsatz tauglich.

Wirklich neues gibt es eigentlich nicht zu vermelden, zumindest nicht bzgl. der eigentlichen Funktion. Ansonsten gibt es nun eine deutsche Übersetzung (ist manchmal gar nicht so leicht *fg*) und ein paar Statistiken, die man sich auch im Dashboard anzeigen lassen kann. Eine kleine Änderung gibt es auch bzgl. des Cache-Verzeichnisses, dieses ist nun direkt in wp-contents und wird somit nicht bei jedem Pluginupdate gelöscht (nur um dann wieder mühsam gefüllt zu werden).

Auf eine Funktion den Cache in einem Rutsch zu erneuern habe ich bisher noch verzichtet, und zwar aus folgenden Gründen:

• Es ist nicht wirklich sicher das alle Bilder im Cache-Verzeichnis auch wirklich noch gebraucht werden.
• Müsste das Skript wohl gesplittet werden, sprich es dürften bei jedem Durchgang nur x Bilder aufgefrischt werden (Timeoutgefahr, was einen Cronjob wieder schwieriger macht).
• Ist das Updaten beim Seitenaufruf (mit der Beschränkung auf max. 3 Bilder/Aufruf) eigentlich schnell genug (und es wird auch wirklich nur das aufgefrischt was wirklich sein muss).

Sollte jemand dafür eine gute Idee haben, immer her damit…

Ansonsten viel Spass mit dem Plugin, und bei Fragen am besten das Forum verwenden (danke).

Ein kleiner Update-Marathon gab es heute bei meinem Plugin “GravatarLocalCache“. Ausgangspunkt war eine mögliche doppelte Konstante (ungeschickt gewählter Name) und eine erweiterte Ausgabe (Debug) bei Problemen mit dem Anlegen des Cache-Verzeichnisses. Hinzu kam noch die Idee, einen Regulären Ausdruck einzusparen, und zwar bei der Auswahl des “Standard”-Gravatars und genau hier entwickelten sich mehr Probleme als erwartet. Irgendwie ist mir der Source-Code von WordPress manchmal nicht ganz klar (und insbesondere nicht gerade logisch) und so hatte ich hier den einen bzw. anderen Fehler eingebaut, um schlussendlich doch wieder auf die ursprüngliche Variante zurückzugreifen (mit ner kleinen Erweiterung, falls es dort ein Problem gibt kommt schlussendlich die WordPress-Einstellung bzgl. des Standard-Gravatars zum tragen).

Vor einem Release der Version 1.0 überlege ich nun noch die Auslagerung des Cacheverzeichnisses, da es ansonsten bei jedem Update gelöscht wird… Gibt es sonst noch Wünsche?

Angeregt durch einen Beitrag von hombertho möchte ich auch einmal einen Einblick geben, welche Plugins in meinem Blog zum Einsatz kommen:

» weiterlesen…

Wie indirekt schon angekündigt, gibt es nun eine neue Version von meinem WordPress Plugin “GravatarLocalCache“.

Ich habe mich nun gegen eine Variante via mod_rewrite/Auslieferung der Bilder via PHP-Skript entschieden und “einfach” die Zahl der vom Skript herunterzuladenden Gravatare pro Aufruf limitiert (es werden nun max 3 Gravatare bei einem Seitenaufruf heruntergeladen). Ich denke das ist ein brauchbarer Kompromiss. Zumal die Bilder nun auch weiterhin direkt (und ohne Overhead) ausgeliefert werden.

» weiterlesen…

Dieses Update stellt einen kleinen Schritt in Richtung bessere Usability dar. Bisher konnte man die Vorschaubilder von Videos nicht von normalen Bildern unterscheiden. Mit Version 1.2.9 werden die Vorschaubilder nun von einem “play”-Button überlagert, so dass die Videos eindeutiger zu identifizieren sein sollten. Die Idee (bzw. die Erinnerung daran) geht auf JustDerek zurück, danke.

» weiterlesen…

Bei den Versuchen die Ladezeit meines Blogs zu verkürzen ist ein neues Plugin für WordPress entstanden: GravatarLocalCache.

Im Grunde sagt der Titel schon alles, mit dem Plugin lassen sich die Gravatar-Bilder auf dem eigenen Server zwischenspeichern und werden von dort ausgeliefert. Doch welchen Vorteil kann das haben?

» weiterlesen…

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.