Category: Plugins

BuddyPress Desktop Notification 0.8 veröffentlicht

Schon seit einigen Wochen hatte ich an der neusten Version von BuddyPress Desktop Notification gearbeitet. Dabei ging es vor allem um die Einarbeitung von Vorschlägen, welche User im Support Forum gemacht haben. Gestern abend habe ich die neuste Version 0.8 nun im Repository von WordPress veröffentlicht.

Kurz zur Erinnerung: Mit diesem Plugin kannst Du den Nutzern Deiner BuddyPress Community die Möglichkeit geben, via Desktop Notification über Neuigkeiten im Netzwerk informiert zu werden.

Was hält die neuste Version bereit?

  1. komplett übersetzbar
  2. und schon inklusive deutscher Sprachdatei
  3. Wenn ein User sich gestört fühlt durch die Benachrichtigungen kann er diese in seinen Einstellungen unter der Sektion Emails abstellen
  4. Einige kleine Bugfixes

Außerdem habe ich für de.wordpress.org eine Übersetzung der Pluginbeschreibung eingereicht. Ich bin mal gespannt wie das System arbeitet und ob man auf https://de.wordpress.org/plugins/buddypress-desktop-notification/ bald einen deutschen Text dafür sieht. Noch heißt es im Übersetzungsbereich das Plugin sei nicht komplett übersetzbar, allerdings verstehe ich nicht ganz warum und tippe darauf, dass diese Information noch aktualisiert werden muss (da das Plugin jetzt über eine Text Domain etc. verfügt).

Vielen Dank an die vielen Nutzer des Plugins, damit hätte ich gar nicht gerechnet als ich mit dem Plugin angefangen hatte.

Die neuen Term Meta-Daten: Wie erstelle ich “Featured Images” für Kategorien?

Ich hatte es ja in meinem letzten Beitrag schon mal kurz anklingen lassen, wollte ich ein wenig mit den Metadaten für Terms experimentieren, welche mit WordPress 4.4 integriert werden. Dazu entwickel ich in diesem Videotutorial ein kleines Plugin, welches die Termmetadaten nutzt, um Kategorien dahingehend zu erweitern, dass diesen ein Kategorienbild hinzugefügt werden kann:

Der Code für dieses Plugin findet Ihr hier:

 

Die Javascript-Datei:

 

Verwendete Actionhooks:

  • category_add_form_fields, bzw. {$taxonomy}_add_form_fields
  • category_edit_form_fields, bzw. {$taxonomy}_edit_form_fields
  • edited_terms
  • created_term
  • admin_enqueue_scripts

Verwendete Bibliotheken und Funktionen:

 

Term Metadaten sind meines Erachtens eine der interessantesten Neuerungen in WordPress 4.4. Nicht nur ist es super, dass wir jetzt eine schöne Möglichkeit haben den Informationsgehalt von Taxonomien beliebig zu erweitern, man kann diese Informationen auch nutzen, um – ganz ähnlich wie im WP_Query – Terms nach bestimmten Metadaten zu filtern.

Ich glaube, daraus ergeben sich noch zahlreiche Anwendungsmöglichkeiten. Wenn Ihr Ideen habt, was man mit diesem neuen Feature noch alles realisieren könnte oder einfach Tipps, Verbesserungsvorschläge oder was auch immer, würde ich mich natürlich über Kommentare freuen.

 

Automatisches Plugin Update auch außerhalb von wordpress.org

Nicht immer platziert man sein Plugin im WordPress Repository. Zum Beispiel, wenn man ein Premium Plugin entwickelt hat, welches man verkaufen möchte. Nun stellt sich natürlich die Frage, wie man seinen Kunden in diesem Fall eine möglichst unkomplizierte Aktualisierungs-Routine zur Verfügung stellen kann.

WordPress verfügt ja für das Repository schon über eine Update Logik und es wäre schön, wenn man sich in diese einhaken kann, um auch das eigene Premium Plugin automatisch aktualisieren zu lassen.

Plugins aktualisieren
In der Plugin Übersicht von WordPress sieht man, welche Plugins aktualisiert werden müssen.

In dem obigen Screenshot sehen wir zwei Plugins, welche aktualisiert werden müssen: Das allseits bekannte Akismet, welches im WordPress Repository zu finden ist, sowie ein Plugin Namens “Autoupdate Tester”. Normalerweise erhält WordPress die Informationen, welches Plugin veraltet ist aus dem Repository. Doch unser Plugin Autoupdate Tester ist dort nicht zu finden. In diesem Beitrag werde ich Schritt für Schritt erklären, wie man für ein Plugin, welches nicht im Repository zu finden ist, eine Updateroutine schreiben kann, die sich nahtlos in WordPress einpasst.

Einhaken, wenn die Aktualität von Plugins geprüft wird

Im ersten Schritt müssen wir herausfinden, wie und wann WordPress prüft, ob ein Plugin veraltet ist. Dies geschieht in der Funktion wp_update_plugins() (wp-includes/update.php). Diese Datei schickt Informationen über alle installierten Plugins an die WordPress API, konkret an http://api.wordpress.org/plugins/update-check/1.1/, und erhält von dort die Information, welches Plugin veraltet ist. Diese Informationen werden dabei aus dem Repository bezogen. Da unser Premium Plugin dort nicht zu finden ist kann aus diesem auch keine Information über den Versionsstatus kommen.

Die Informationen, welche Plugins aktualisiert werden müssen und so weiter, legt WordPress am Ende schließlich als Transient ab. Mit Hilfe der Transient API kann man Daten für eine gewisse Zeit in der WordPress Datenbank speichern und so den Server entlasten. Das ist für uns insoweit von Interesse, als wir uns genau an dieser Stelle einhaken können, denn die Transient API verfügt über ihre ganz eigenen Filterhooks. So speichert wp_update_plugins() über die Funktion set_site_transient() die Update-Informationen im Transient 'update_plugins'. Mit dem Filter 'pre_set_site_transient_update_plugins' können wir diese Informationen nun abändern, bevor sie in der Datenbank abgelegt werden.

Die Plugin-Update Information

Der Transient ist ein std Class Objekt, welches unter anderem den Array response enthält. Dieser Array enthält alle veralteten Plugins und in diesen Array möchten auch wir unser Plugin einschreiben, sollte es veraltet sein. Der Array-Schlüssel ist dabei der Plugin Slug, welcher unter Verwendung von plugin_basename() ermittelt werden kann. Hinter diesem Schlüssel verbirgt sich nun erneut ein std Class Objekt mit folgenden Informationen:

plugin, slug
Diese beiden Werte enthalten den Plugin Slug, welcher über plugin_basename() ermittelt werden kann.
new_version
Hier wird die neue Versionsnummer abgelegt.
url
Hier wird die URL zum Plugin hinterlegt.
package
Das ist die zentrale Information! Hier wird die URL zum aktuellen Plugin-ZIP hinterlegt!

Einhaken, Versionsprüfung, Ablegen

Mit diesen Informationen können wir unser kostenpflichtiges Plugin schon in den Update Prozess einhaken und WordPress prüfen lassen, ob das Plugin veraltet ist.

Dazu haken uns in den Filter 'pre_set_site_transient_update_plugins' ein. Natürlich müssen wir irgendwo hinterlegt haben, welche Versionsnummer derzeit aktuell ist. Mit wp_remote_get() greifen wir diese Information deshalb ab (Wer am Unterschied zwischen wp_remote_get() und wp_safe_remote_get() interessiert ist, kann dies in diesem Blogbeitrag erfahren.). Im Anschluss nutzen wir die Funktion get_plugin_data(), um die Daten des aktuell installierten Plugins zu erfahren. Sollte die Versionsnummer des aktuellen Plugins kleiner sein als die Versionsnummer, welche wir über wp_remote_get() erhalten haben, fügen wir nun unser Plugin in den Transient mit ein.

Die plugins_api(), beziehungsweise: Noch ein letzter Schritt

Wenn unser Plugin, dessen aktuelle Version wir außerhalb des Repositories hosten, veraltet ist wird WordPress uns dies nun anzeigen. Das genügt allerdings noch nicht. Uns fehlen noch Informationen wie die Kompatibilität zur aktuellen WordPress Version, Changelog und ähnliches. Diese werden von der Funktion plugins_api() (wp-admin/includes/plugin-install.php) zur Verfügung gestellt. Wie schon zuvor wird dabei auf Informationen aus dem WordPress Repository zurückgegriffen. Nun wollen wir diese Informationen im gewohnten WordPress Interface für unser Plugin zur Verfügung stellen. Auch diese Funktion ermöglicht es uns, mit Hilfe eines Filters den Output zu übernehmen: 'plugins_api'.

Weitere Informationen über das Update in der WP Thickbox
Weitere Informationen über das Update in der WP Thickbox

Auch in diesem Fall müssen wir über zwei Seiten vorgehen. Auf der Serverseite brauchen wir eine Datei, welche die Informationen zur Verfügung stellt. Dabei handelt es sich um ein std Class Objekt. Und clientseitig, also in unserem Plugin, müssen wir uns in den Filter einhaken und die Informationen mit wp_remote_get() abrufen.

Serverseitig

Schauen wir uns zunächst die Informationen an, welche unser Remote Server übergeben muss:

Wie sie sehen übermitteln wir einfach ein serialisiertes stdClass Objekt, deren Inhalt sich eigentlich selbst erklärt. Es wird nochmals die aktuelle Version übergeben, bis zu welcher WordPress Version diese getestet wurde, wann das Update stattgefunden hat und wir erhalten auch die unterschiedlichen Sektionen, welche in der Thickbox, welche wir öffnen, wenn wir auf “weitere Informationen” klicken, erscheinen.

Clientseitig

Nun müssen wir diese Informationen clientseitig im entsprechenden Filter entgegennehmen:

Wir fragen also zunächst ab, ob plugins_api() im aktuellen Fall für unser Plugin ausgeführt wird. Ist dies der Fall setzen wir einen Request ab, fordern die Daten von unserem Remote Server an und übergeben diese. So haben wir nun auch diese Informationen zur Hand und stellen Sie dem WordPress Administrator zur Verfügung.

Schluß

Mit Hilfe der Filter 'pre_set_site_transient_update_plugins' und 'plugins_api' können wir uns schnell und einfach in die WordPress Plugin Update Routine einklinken und auch Plugins, welche außerhalb des Repositories gehostet werden updaten. Dieser Blogbeitrag wäre nicht möglich gewesen ohne diese schöne Klasse, welche eigentlich alles notwendige nochmal etwas eleganter zusammenfasst. Zwei Tage nachdem Sergej Müller sich aus der Community verabschiedet hat, sieht man mal wo er doch noch immer anzutreffen ist. So gehört er zu den Contributern der wp_autoupdate.php. Vielen Dank!

BuddyPress Desktop Notification

Mein neustes Plugin wurde gerade auf wordpress.org veröffentlicht: “BuddyPress Desktop Notification“. Wenn Du eine BuddyPress Community betreibst, kannst Du dieses Plugin nutzen, um neue Nachrichten, Aktivitäten oder Freundschaftsanfragen von Nutzern anzeigen zu lassen.

BuddyPress Desktop Notification
Eine Benachrichtigung mit BuddyPress Desktop Notification

Wie das funktioniert? Nachdem der Nutzer sich eingeloggt hat fragt ihn der Browser, ob er Desktop Notifications zulassen möchte. Diese funktionieren mit den meisten modernen Browsern (eine aktuelle Übersicht gibt es hier). Während normale Benachrichtigungsplugins einfach ein kleines Popup oder etwas ähnliches aufleuchten lassen, werden Desktop Notifikationen sogar angezeigt, während der Browser minimiert ist:

Desktop notification works also with minimized browsers
Desktop Notification funktionieren auch, wenn der Browser minimiert ist

Es ist ein ziemlich kleines Plugin, kann jedoch relativ viel Traffic verursachen, da jeder eingeloggte Benutzer, welcher Notifikationen zulässt, alle fünf Sekunden eine Ajax Anfrage startet, ob es Neuigkeiten gibt. Ich habe mich dazu entschieden, das Plugin über Filter konfigurierbar zu machen, da ich – um ehrlich zu sein – kein besonders großer Fan überfrachteter Admin Menüs bin. Wenn das Plugin also zu viel Traffic verursacht, kann man das Request Intervall mit Hilfe von PHP vergrößern:

Weitere Informationen zu BuddyPress Desktop Notification finden sich auf der Webseite.

WordPress Alternative zu Google Analytics: Statify

Nach wie vor ist Google Analytics der Platzhirsch wenn es um Webstatistiken geht. Doch es gibt eine Vielzahl von Gründen, warum jemand Analytics nicht mehr nutzen möchte. Datenschutz ist nur einer von vielen. Zahlreiche Alternativen buhlen um die Aufmerksamkeit der Administratoren. Ich möchte Euch heute eine vorstellen: Das WordPress Plugin Statify von Sergej Müller.

Gerade wenn Ihr Euch um den Datenschutz Eurer Besucher sorgt solltet Ihr einen Blick auf dieses kleine Plugin werfen, welches eine transparente Lösung liefert und die Besucherdaten vor allem nicht an Dritte weitergibt. Darüber hinaus verwendet Statisfy weder Cookies noch zeichnet es die IP Adresse der Besucher auf, um diese nachzuverfolgen:

Im direkten Vergleich mit Webstatistik-Diensten wie Google Analytics, WordPress.com Stats oder Piwik speichert Statify weder perfönliche Daten wie IP Adressen noch werden diese weiterverarbeitet – Statify zählt Seitenbesuche, nicht Besucher

Darüber hinaus kann man selbst bestimmen, wie lange die Daten in der zusätzlichen Datenbank gespeichert werden sollen, welche mit nur vier Spalten ziemlich übersichtlich daher kommt.

Obwohl das Plugin also sehr übersichtlich gestaltet ist, erhält man trotzdem was man möchte; Eine saubere und schöne Übersicht über die Besucher:

Besucher Statistik mit Statify
Besucher Statistik mit Statify

Statisfy läuft derzeit auf über 20,000 Webseiten und erhält fast durchgehend gute Rezensionen, wie diese, welche die Hauptvorteile des Plugins hervorhebt:

Die Stärke von Statify liegt in seiner Einfachheit. Man hat es mit zwei Mausklicks eingerichtet und erhält ein kleines Widget im Dashboard, welches eine Statistik des letzten Webtraffics enthält, die Referrer sowie die aktivsten Seiten anzeigt – gerade genug Daten um ein bißchen Feedback über die Popularität der eigenen Seite zu erhalten. Da diese Informationen nicht mit einer dritten Partei geteilt werden genügt das Plugin damit auch den deutschen Gesetzen des Datenschutzes.

Ein weiterer Vorteil des Plugins liegt in dem sehr guten Support den Sergej Müller meistens anbieten kann. Ich selbst hatte gesehen wie er ein kleines Problem auf Google+ innerhalb weniger Minuten löste und das entsprechende Patch in das WordPress Repository einspielte. Kriegt man einen solchen Service bei GA? Ich zumindest habe heute gewechselt. Wie steht es mit Dir?