In den letzten Wochen hatte ich mit einigen WordPress-Themes und -Plugins zu tun, die mich veranlasst haben diesen Artikel zu schreiben.
Wenn man nach WordPress und API googelt, gewinnt man den Eindruck, es gibt einzig und allen die REST-API, man muss mehrere Ergebnisseiten nach hinten blättern bis man überhaupt den Eindruck gewinnen kann, das es noch andere APIs gibt.
Eine Übersicht der von WordPress bereitgestellten APIs findet sich im Core APIs Handbook.
Warum soll ich die API nutzen?
Nehmen wir zum Beispiel ein Plugin, das Daten von einen externen Dienst per http lädt. Gängige Verfahren, die ich schon in Plugins gesehen habe, wären das direkte Nutzen der curl Erweiterung von PHP, was aber voraussetzt, das diese beim jeweiligen Hoster auch installiert ist – dies ist nicht immer der Fall. Sollte bei einem Hoster die curl-Erweiterung nicht verfügbar sein, so ist das Plugin leider nicht nutzbar. Eine andere beliebte Methode ist, per composer eine Bibliothek wie beispielsweise Guzzle einzubinden.
Leider ist es nun nicht möglich, mit anderen Plugins auf die Kommunikation nach außen Einfluss zu nehmen. Die von WordPress bereitgestellten APIs sind durchzogen von sogenannten Hooks, mit denen das Verhalten bzw. die Daten an unterschiedlichen Stellen verändert werden können. Erst durch dieses Verfahren ist es überhaupt möglich, das WordPress durch Plugins erweiterbar ist, und diese auf WordPress und auch auf andere Plugins Einfluss nehmen können.
Um beim Beispiel der http Verbindung zu bleiben, die WordPress HTTP-API kann per curl, fopen und per Socket eine Verbindung nach außen herstellen. Dazu prüft die API, welche Möglichkeiten auf dem jeweiligen System zur Verfügung stehen und wählt die passende Verbindungsmethode. Durch die Hooks (Filter und Aktions) innerhalb der HTTP-API ist es z.b. möglich, das Plugins wie Snitch die ausgehenden Verbindungen protokollieren. Ebenso ist es möglich durch die WP_PROXY_ (HOST, PORT, USERNAME, PASSWORD, BYPASS_HOSTS) Konfigurationsdirektiven den Datenverkehr umzuleiten, zum Beispiel um den ausgehenden Datenverkehr durch einen lokalen Proxy zu schicken, um zu analysieren, welche Daten mit einem Drittserver ausgetauscht werden.
All das ist nicht möglich, wenn statt der WordPress API etwas anderes verwendet wird.
Auch außerhalb der von WordPress bereitgestellten APIs sollte immer geschaut werden, ob WordPress eine eigene Funktion zur Verfügung stellt. Das beste Beispiel dafür ist der Versand von E-Mails. Verwendet man die mail() Funktion von PHP, werden die Mails an WordPress vorbei direkt über das lokale Mailsystem des Webserver versendet. Im Bereich des Shared Hostings gibt es meistens keine Möglichkeit, dieses zu verändern. Wird stattdessen die wp_mail() Funktion, die WordPress bereitstellt verwendet, kann der Mailversand durch Plugins beeinflusst werden. Beispielsweise durch eines der vielen SMTP-Plugins, die erlauben das Mails über einen externen Mailserver zu versenden, statt über den Webserver.
Kurz gesagt, geht den WordPress Weg und bau nicht drumherum.
Ein wichtiger Artikel! Ich freue mich auch jedes Mal, wenn Plugins es richtig machen und die diversen APIs verwenden, bzw. bin frustriert, wenn sie es nicht tun.
Bei Guzzle vs. WordPress API kann ich einige ja sogar verstehen, weil Guzzle einem sehr viel abnimmt, das man sonst dazu programmieren muss. Ich habe mir hier für meine Plugins selbst eine kleine Hilfsklasse geschrieben und mich dabei an “WooCommerce/Admin/WC_Helper_API” orientiert.
Durch meine Arbeit auf WP VIP Hosting habe ich in letzter Zeit auch etwas mehr mit der “Filesystem API” gearbeitet. Es ist am Anfang auch erst mal ein größerer Overhead, statt einfach die PHP API zu verwenden. Aber wenn man mit einem “immutable storage” arbeitet, dass ist eben eine solche API unverzichtlich.
Die HTTP API von WordPress ist kein vollständiger Ersatz für Guzzle o. ä., weil sie die Methoden PUT und DELETE nicht unterstützt.