Ich habe heute zum ersten Mal einen »Workflow« mit »GitHub Actions« erstellt, um eine Travis-CI-Integration zu ersetzen. Erfreulicherweise ging das recht schnell von der Hand. Hier möchte ich den Prozess als kleinen Einstieg in das Thema beschreiben.

Bei dem Workflow geht es darum, das DEWP-Planet-Feed-Plugin nach Erstellen eines GitHub-Releases in einer direkt nutzbaren Form an den Release anzuhängen, damit Nutzerinnen und Nutzer nicht lokal NPM anwerfen und dann Webpack ausführen müssen, bevor sie es nutzen können.

Weiterlesen

Die REST-API ist ein Teil von WordPress, mit dem ich relativ selten direkt kommuniziere. Wenn, geht es oft um Filtermöglichkeiten für eine Post-Liste, die im Frontend angezeigt wird, das heißt: Der Website-User ändert einen Filter, wodurch im Hintergrund eine Anfrage an die REST-API geschickt und die Liste mit den Daten der Antwort angepasst wird.

Bis vor Kurzem habe ich dabei immer einiges an HTML innerhalb von JavaScript erzeugt, um das Markup für die einzelnen Posts mit den Daten der REST-API-Antwort zu erstellen. Immer mit Umständlichkeiten oder Dingen, die sich nicht einfach umsetzen lassen, etwa Markup für Responsive Images, das sonst bei bestimmten Bildfunktionen von WordPress direkt mit erstellt wird.

Beim letzten Anwendungsfall kam mir dann der Gedanke, ob das nicht auch schlauer geht.

Weiterlesen

WPScan ist ein Werkzeug, um Sicherheitslücken in WordPress-Installationen zu finden. Dafür werden die Version vom WordPress Core, von Themes und Plugins gegen die WPScan Vulnerability Database geprüft, die Sicherheitslücken in eben diesen drei Teilen von WordPress listet.

Einsetzen lässt sich WPScan mit einem WordPress-Plugin, als Kommandozeilen-Tool oder als Software as a Service (SaaS).

Weiterlesen

Wer schon mal an WordPress oder einem der Plugins und Themes in den offiziellen Verzeichnissen mitübersetzt hat, wird translate.wordpress.org kennen – eine Plattform, auf der die Übersetzungen für (unter anderem) den WordPress-Core und viele tausend Plugins und Themes gepflegt werden.

Dahinter steht GlotPress, das es als WordPress-Plugin gibt, sodass sich theoretisch jeder und jede selbst eine solche Plattform aufsetzen kann, um zum Beispiel Übersetzungen für Plugins und Themes von Kundenprojekten zu pflegen (oder andere pflegen zu lassen), ohne für jedes Übersetzungsupdate auch ein Update des Themes oder Plugins bereitstellen zu müssen.

Für ein bisschen mehr Komfort dabei sorgt Traduttore, entwickelt von required, das zum Beispiel automatisch Strings aus Code-Repositorys extrahieren und Sprachpakete erstellen kann, auf die eine WordPress-Installation dann zugreift, als würden sie von translate.wordpress.org kommen.

Weiterlesen

Im Block-Editor können wiederverwendbare Blöcke erstellt werden. Diese Blöcke lassen sich dann wie Core- und Plugin-Blöcke normal einfügen. Sobald eine Instanz dieses Blocks bearbeitet wird, wird überall diese aktualisierte Version ausgespielt.

Ein nützlicher Anwendungsfall für diese wiederverwendbaren Blöcke ist beispielsweise die Darstellung von Team-Mitgliedern, wenn einzelne davon auch auf anderen Seiten als Ansprechpartnerinnen und Ansprechpartner angezeigt werden sollen. Hier zeige ich, wie sich diese Blöcke zwischen mehreren Sites einer Multisite synchronisieren lassen, um über das gesamte Netzwerk hinweg immer den aktuellen Stand anzuzeigen.

Weiterlesen

Seit WordPress 5.0 können auch in JavaScript Übersetzungsfunktionen genutzt werden. Beim Bau von Gutenberg-Blöcken sind die sehr nützlich, allerdings gibt es ein paar Hürden bei der Übersetzung, wenn das Plugin mit dem Block nicht im offiziellen WordPress.org-Verzeichnis liegt. Hier zeige ich, wie Übersetzungen für Blöcke angelegt werden können.

Voraussetzungen

Neben einem Plugin, in dem wir JS-Strings übersetzen möchten, brauchen wir WP-CLI 2.2.0 oder neuer. Falls ihr das Tool noch nicht installiert habt, findet ihr auf der Installing-Seite des WP-CLI-Handbuchs verschiedene Möglichkeiten dafür.

Weiterlesen