![Techgedöns [tɛçgədøːns]](https://tchgdns.de/wp-content/themes/tchgdns/images/header.png "Techgedöns [tɛçgədøːns]")
Marcel
Fast auf den Tag genau vor einem Jahr ist Version 3.0 meines WordPress-Plugins WP-Appbox veröffentlicht worden, nun habe ich mit der Version 4.0 nachgelegt. In der Zwischenzeit sind einige kleinere Updates auf den Weg gebracht worden und viele bloggende Kollegen sind hinzugekommen. Lag die Zahl der aktiven Installationen laut WordPress vor rund einem Jahr noch bei etwa 2.000 Installationen, weist der Zähler inzwischen 4.000 aktive Installationen auf. Bin ich noch immer völlig geflasht von, vor allem weil das ganze damals wie heute ein Hobby-Projekt ist und der Ursprung in einer persönlichen „Notwendigkeit“ lag. Daher zunächst einmal ein dickes Danke an alle, die das Plugin nutzen und vor allem bei jenen, die bei etwaigen Fehlern und Problemen die ruhe Bewahren und bei der Fehlersuche helfen. DANKE für sämtliche Unterstützung.
Nun aber zur Version 4.0, mit der sich einiges geändert hat – wenn ihr es denn so möchtet. Denn soweit ich es nachvollziehen kann (und ich habe immer ein kleines Auge auf meine „Schäfchen“) läuft die Appbox überraschend recht rund, sodass in meinen Augen eigentlich keine großen Änderungen notwendig gewesen wären. Dennoch habe ich mit der Version 4.0 ein paar größere Implementierungen vorgenommen und den Fokus vor allem auf den Cache gelegt, was vor allem für Seiten mit höherem Traffic-Aufkommen einen Mehrwert mitbringt. Aber auch abseits dieser größeren Neuerungen finden sich hier und da ein paar kleinere Änderungen vor, die ich an dieser Stelle einmal auflisten und gegebenenfalls ein wenig ausführlicher erklären möchte.
Entfernte Apps verbleiben in der Datenbank
Status Quo: Bislang war es so, dass Apps nach Ablauf des Cache erneut abgefragt wurden. Wurde die App gefunden wurden die Daten (wenn notwendig) aktualisiert, wenn nicht gab es eine Fehlermeldung, dass die App nicht gefunden wurde. Entfernte Apps wurden demnach immer aus der Datenbank entfernt und unterschieden sich nicht von falschen IDs oder ähnlichem.
Version 4.0: Der Mechanismus wurde dahingehend geändert, dass die Daten von aus den Stores entfernten Apps in der Datenbank verbleiben und markiert werden – so gibt es auch nach zwei, drei Jahren keine „App nicht gefunden“-Boxen. Damit die Besucher zwischen vorhandenen und nicht mehr vorhandenen Apps unterscheiden können, habe ich dem umgebenden „wp-appbox“ eine weitere Klasse „deprecated“ spendiert (oder aber die Variable {DEPRECATED} für die Templates), über die sich derartige Ausgaben anpassen lassen. Die Standard-Templates haben es natürlich schon integriert, wobei ich habe viel ausprobiert habe. Die Lösung, den Titel und Link durchzustreichen und das App-Icon auszugrauen empfand ich als am stimmigsten. Aber: Könnt ihr natürlich beliebig anpassen.
Automatische Aktualisierung via WP-Cron
Status Quo: Bislang gab es drei Möglichkeiten, wie man App-Informationen erneut abfragen konnte. Standardmäßig wurden die Informationen abgefragt, sobald ein Besucher die (ungecachte) Seite aufgerufen hat und die Informationen im Cache veraltet waren. Alternativ dazu ließ sich die automatische Aktualisierung beim Seitenaufruf auch nur für eingeloggte Nutzer aktivieren oder aber komplett abschalten, sodass dies lediglich über den manuellen Reload-Button (nur für Autoren sichtbar) in dem Appbox-Badge passierte.
Version 4.0: Die neue Version bringt nun auch eine automatische Aktualisierung im Hintergrund via WP-Cron/Cronjob mit sich, was vor allem für „High-Traffic-Seiten“ einen Nutzen birgt, aber natürlich auch für jede andere Seite. Die Option ist noch experimentell (läuft bei mir aber) und muss zuvor in den erweiterten Einstellungen des Plugins doppelt aktiviert werden, danach taucht die Option dann in den Cache-Einstellungen auf und kann aktiviert werden. In welchem Intervall der Cronjob ausgeführt werden soll und wie viele Apps abgefragt werden sollen, könnt ihr ebenfalls festlegen. Es werden immer die x ältesten Apps neu abgefragt. Experimentell ist die Option aus dem Grunde, dass es hier nach und nach Änderungen geben kann, langfristig soll es aber die Standard-Methode werden.
Das gibt es zu beachten: WP-Cron läuft zwar im Hintergrund, verbraucht aber dennoch Ressourcen auf dem Server. Wer nur einen 10-Euro-Webspace besitzt und alle drei Minuten 100 Apps aktualisiert, der wird unter Umständen Probleme bekommen. Auch findet es vor allem Google nicht so dolle, wenn euer Server innerhalb von wenigen Minuten oder Sekunden duzende Anfragen stellt. Es gilt also: Je mehr Power, umso kürzer kann der Intervall und die App-Anzahl sein. Die Anzahl sollte aber nicht zu hoch liegen, um einen (temporären) Block der Server zu verhindern. Die grundsätzliche Problematik des WP-Cron (wird nur bei Seitenaufruf abgefragt) lasse ich mal außen vor, große Seiten nutzen sowieso einen „echten“ Cronjob auf dem Server.
Caching von App-Icons und Screenshots
Status Quo: Bisher wurden in der Datenbank lediglich die URLs zu den Bildern (App-Icons und Screenshots) gesichert, eine Zwischenspeicherung der Bilder auf dem eigenen Server gab es nicht, stattdessen wurden die Bilder immer erneut von den Servern der Anbieter geladen. Dies führte dazu, dass man immer etwas von der Reaktionszeit der Server anhängig war und dass es gerade bei Apple zu Problemen kam, denn trotz HTTPS-Protokoll ihrer iTunes-Links verwendet man lediglich HTTP-Bilder. Zwar ist es über einen kleinen Workaround möglich, SSL-Bilder zu verwenden, es gibt jedoch wenige Ausnahmen, bei denen keine SSL-Version des Bildes zur Verfügung steht. Grundsätzlich funktionierte die Methode, es geht jedoch auch anders.
Version 4.0: Mit der neusten Version lassen sich die Bilder auch auf dem eigenen Server speichern. Optional, muss aktiviert werden. Gespeichert werden die Bilder im Ordner „wp-content/cache/wp-appbox„, einer dieser Ordner muss zur Aktivierung also mit Schreibrechten versehen werden. Ihr könnt auch auswählen, ob nur das App-Icon (sinnvoll bezüglich „App entfernt“) oder auch die Screenshots gespeichert werden sollen. Damit identische Bilder nicht immer erneut heruntergeladen werden, könnt ihr zum einen eine Cache-Zeit für die Bilder festlegen, zum anderen werden Bilder nur dann erneut heruntergeladen, wenn sich die URL geändert hat. Hat sich bewährt, wobei alte, nicht mehr benötigte Bilder gleichzeitig gelöscht werden.
Nutzung mit Cache-Plugin: Die Speicherung der Screenshots führt in Kombination mit einem Cache-Plugin wie W3C oder Cache Enabler zu einem Problem. Wird die App mitsamt Bildern aktualisiert, so verweisen alte Seiten noch auf die alten Bilder, die aber nicht mehr verfügbar sind. Aus diesem Grunde könnt ihr eine Option nutzen, bei der alte, ausgetauschte Bilder erst nach Ablauf einer bestimmten Zeit gelöscht werden. Idealerweise sollte die Zeitspanne identisch sein zu jener eures Cache-Plugins, denn in dem Falle sind die Bilder grundsätzlich so lange verfügbar, wie der Seiten-Cache exisitiert.
Das gibt es zu beachten: Irgendwie müssen die Bilder ja von Server A zu Server B gelangen – und dass nimmt bei der Abfrage mehr Ressourcen und Zeit in Anspruch. War in meinem Test hier nicht absolut grausam, aber es ist eben doch spürbar. Zwar findet das Laden der Bilder nur bei einer Aktualisierung statt (wenn URLs gleich geblieben, werden sie nicht erneut geladen, siehe oben), es ist aber vorhanden und der Grund, wieso das Screenshot-Caching als „experimentell“ markiert ist. Wer die Aktualisierung via WP-Cron nutzt, der wird davon weniger bemerken, da es eben im Hintergrund geschieht – benötigt aber wie der Cronjob generell dann mehr Ressourcen. Müsst ihr unter Umständen mal ausprobieren, ob ihr App-Icons und Screenshots cachen lasst und welchen Cache-Mode ihr verwendet.
Nicht gefundene Apps die Zweite
Status Quo: Wurde eine App nicht im jeweiligen Store gefunden, so war es bislang so, dass diese immer und immer wieder abgefragt wurde, wenn die (ungecachte) Seite aufgerufen wurde. Bei entfernten Apps erübrigt sich dies nun, wenn ihr aber zum Beispiel die ID einer App eingefügt habt, die erst im Laufe der Zeit aktiv geschaltet wird, kann dies bei vielen Besuchern schnell mal in einem (temporären) Block enden.
Version 4.0: Genau aus diesem Grunde lassen sich Abfragen für nicht gefundene Apps für eine bestimmte Zeit blockieren und erst nach Ablauf der Sperrfrist wird die App bei einem erneuten Seitenaufruf wieder abgefragt. Dies betrifft nur Apps, die sich noch nicht in der Datenbank befinden – wird sie nicht gefunden, weil sie nicht entfernt wird, greift der reguläre Cache. Außerdem habe ich die Fehlermeldung für nicht gefundene Apps ein wenig überarbeitet und für eigene Templates steht euch nun auch das Template „error.php“ zur Verfügung, mit dessen Hilfe ihr eine eigene Fehlerausgabe erstellen könnt – wenn ihr wollt.
Weitere, kleinere Änderungen
- Alexa Skills haben nun ein eigenes Symbol für den Store im Appbox-Badge, als CSS-Klasse findet „.amazonalexa“ Verwendung
- Das Android-Logo im WYSIWYG-Editor wurde gegen das Logo des Play Store ausgetauscht. Die Farben habe ich etwas verdunkelt, das Original ist schon sehr knallig.
- Ausgehende Links können nun via Anon.to anonymisiert werden, hierbei wird der Referrer entfernt. Fragt nicht, wurde vor allem von ausländischen Seiten häufiger gewünscht.
- Sämtliche Aktivitäten und Fehlermeldungen lassen sich nun auch in ein PHP-Error-Log auf dem Webserver schreiben. Außerdem gibt es im Info-Tab in den Plugin-Einstellungen ein kleines Log – einfach den Info-Tab aufrufen und an die URL ein „&showerrorlog“ anfügen. Benötigt man eigentlich nicht, kann aber bei (m)einer Fehlersuche hilfreich sein.
- Niemandem aufgefallen? Bewertungen gab es bisher nur als ganze Sterne, was aber nicht vorgesehen war. Logisch, wenn das Datenbankfeld einen Integer erfordert. Ist gefixt, nun werden auch halbe Sterne angezeigt.
- Kleinere Optimierungen und Fehlerkorrekturen, aber wir wollen es ja kurz halten
Abschließende Worte
Soviel einmal als Einblick in die Version 4.0 und ein paar Gedanken dazu, zumindest was die wichtigsten Punkte betrifft. Version 4.0 ist kein neues Plugin, trotzdem hat sich im Hintergrund auch abseits der Erwähnungen hier und da etwas geändert. Ich habe die (fertige) Version (inzwischen auch mit WP-Cron und Bilder-Caching) seit etwa zwei Wochen auf meinem Server laufen, einige Features waren hier noch länger aktiv. Darüber hinaus durfte ich auch andere Server als Testobjekte „missbrauchen“ und bisher sind mir keine großen Probleme untergekommen – sieht man mal von den erwähnten Dingen ab, die aber in der Natur der Sache liegen.
Ich habe also das Möglichste getan um ein reibungsloses Update zu verteilen, dennoch sind Probleme leider nie gänzlich ausgeschlossen, einfach aufgrund exotischen unterschiedlichen Server-Settings, Themes und Plugins. Sollte es zu Problemen kommen: Haut mich via Twitter, Mail oder hier in den Kommentaren an und ich versuche euch schnellstmöglich zu Hilfe zu kommen. Sollte es einmal spontan nicht möglich sein: Einfach die alte Version installieren, ist ja möglich. Wollen wir aber mal hoffen, dass vor allem die neuen Funktionen (die die eigentliche „Gefahr“ darstellen) rund laufen – das Update ist wie gesagt soeben live gegangen.
