Unterstützt das Theme mein Plugin?

Es ist gute Praxis, Funktionalität und Layout in WordPress auseinanderzuhalten und deshalb auf der einen Seite Plugins einzusetzen und auf der anderen Themes. Doch die Abgrenzung ist nicht immer scharf zu ziehen. Ein Beispiel wäre, wenn mein Plugin einen eigenen Posttypen entwickelt, welches sich möglichst nahtlos in das Theme einpassen sollte. Doch eine single.php für den neuen Posttype sollte dann entsprechend im Theme vorhanden sein.

So prüft beispielsweise WooCommerce, ob das aktuelle Theme das Plugin unterstützt oder nicht. Wenn das Theme keine Unterstützung deklariert gibt WooCommerce einen entsprechende Meldung im Admin aus. Soll sich dann niemand wundern, dass die Produktpräsentation nicht so aussieht, wie man sich das gewünscht hätte.

WooCommerce prüft, ob das Theme mit dem Plugin kompatibel ist
WooCommerce prüft, ob das Theme mit dem Plugin kompatibel ist

In diesem Beitrag werde ich Schritt für Schritt darstellen, wie man selbst eine solche Überprüfung durchführen kann und entsprechend eine Benachrichtigung im Admin hinterlässt.

Erster Schritt: Das Theme

Zunächst müssen wir uns natürlich fragen, wie ein Theme signalisiert, dass es das entsprechende Plugin unterstützt,beispielsweise indem es eine entsprechende single-{posttype}.php zur Verfügung stellt. WordPress stellt seit Version 2.9 mit add_theme_support() (zu finden in wp-includes/theme.php) eine praktische Schnittstelle bereit, welche wir dazu nutzen möchten. Die Funktion akzeptiert zwei Parameter, das entsprechende Feature, welches unterstützt werden soll, sowie weitere Argumente. Wir konzentrieren uns hier nur auf den ersten Parameter.

Normalerweise unterstützen Themes Beitragsbilder (post-thumbnail) oder benutzerdefinierte Hintergründe im Customizer (custom-background). Doch auch wir können uns einfach ein Feature überlegen und der Themeautor kann mit add_theme_support() dieses dann unterstützen. Sagen wir unser Feature heißt “plugin_theme_support“, so könnte der Themeautor nun mit folgendem Code die Unterstützung für dieses Feature signalisieren:

Zweiter Schritt: Das Plugin prüft

Im zweiten Schritt müssen wir in unserem Plugin nun natürlich überprüfen, ob das aktuelle Theme das Feature “plugin_theme_support” unterstützt. Ebenfalls seit Version 2.9 gibt es dazu die Funktion current_theme_supports(). Auch diese Funktion nimmt als ersten Parameter den Featurenamen und als zweiten optional weitere Argumente auf. Bleiben wir in unserem Beispiel zunächst einfach beim Namen. Wichtig ist zu bedenken, dass wir diese Abfrage erst sinnvoll durchführen können, wenn das Theme seine Unterstützung schon deklariert hat. Dies geschieht normalerweise im Actionhook after_setup_theme.

Am Ende möchten wir einen Admin Notice haben, welcher anzeigt, dass das aktuelle Theme unser Plugin nicht unterstützt. Diesen wollen wir allerdings auch ausblenden können, so dass er den Admin nicht mit jedem Page Load stört. Dazu hinterlegen wir uns eine Option, ob der Administrator den Hinweis angezeigt bekommen möchte. Über einen Button kann er dann den Hinweis abstellen. Während wir prüfen, ob das aktuelle Theme das Plugin unterstützt prüfen wir zugleich, ob ein entsprechender Hinweis dargestellt werden soll. In einer letzten Aktion möchten wir, sollte der Hinweis abgestellt sein, diesen wieder aktivieren, wenn der Administrator das Theme wechselt, so dass er zumindest darauf hingewiesen wird, dass auch das neue Theme nicht mit unserem Plugin kompatibel ist.

Die Prüfung vornehmen

Die Prüfung nehmen wir in dem Actionhook admin_print_styles vor. Wir könnten auch einen anderen nehmen, solange er vor admin_notices ausgeführt wird. Mit get_option() ziehen wir uns zunächst die Information, ob der Hinweis angezeigt werden soll. current_theme_supports( 'plugin_theme_support' ) dient uns dazu, herauszufinden, ob unser Plugin unterstützt wird. Sollte das Plugin keine Unterstützung finden und der Hinweis angzeigt werden, klinken wir uns in den Actionhook admin_notices ein.

Den Hinweis anzeigen

Der admin_notices ist ausschließlich dafür verantwortlich, Hinweise im Admin darzustellen. Deshalb geben wir hier einfach nur unseren HTML-Code aus, welcher im Notice dargestellt werden soll.

Einzig interessant hier ist unser Button, welchen wir einbinden. Mit Hilfe des GET-Parameters hide_theme_support_notice möchten wir später abfragen, ob der Administrator auf den “Hinweis verbergen”-Knopf gedrückt hat. Wir verwenden zur Konstruktion der URL dabei die Funktion add_query_arg(), welche die aktuelle URL um einen weiteren Parameter erweitert. Die Ausgabe von add_query_arg() escapen wir dabei unter zuhilfenahme von esc_url und verhindern damit eine mögliche XSS Attacke.

Unser Admin Notice im WordPress Dashboard
Unser Admin Notice im WordPress Dashboard

Den Hinweis verstecken

Nun müssen wir die Funktionalität des Buttons herstellen, damit der Hinweis auch tatsächlich versteckt wird. Auch hierzu klinken wir uns in die admin_print_styles, könnten aber auch einen anderen Hook nutzen. Wir prüfen einfach, ob der GET-Parameter entsprechend übergeben wurde. Ist dem so, setzen wir unsere Option auf den Wert 1.

Nur für den Spannungsbogen diesen Beitrags habe ich diesen Code in eine neue Funktion gepackt. Natürlich würde man ihn besser in unserer ersten Funktion plugin_theme_support() mit verarbeiten. Wenn man ihn allerdings in eine zweite Funktion packt, sollte man darauf achten, dass diese vor plugin_theme_support() ausgeführt wird.

Den Notice wieder darstellen, wenn das Theme wechselt

Sollte das Theme nun gewechselt werden, möchten wir – falls nötig – die Meldung wieder ausgeben. Dazu klinken wir uns in den Actionhook switch_theme ein. Diese Aktion wird ausgeführt, wenn das Theme gewechselt wird. In dieser setzen wir unsere Option plugin_theme_support also schlicht zurück.

Schluss

Mit diesen simplen Schritten kann man also selbst eine eigene Prüfung vornehmen, ob das aktuelle Theme das eigene Plugin unterstützt und wenn dem nicht so ist kann man im Dashboard einen Hinweis hinterlassen, welchen der Administrator aber auch abstellen kann.

The following two tabs change content below.
Seine erste Webseite hat David Remer 1998 in HTML verfasst. Wenig später war er fasziniert von DHTML und JavaScript. Heute konzentriert sich vor allem auf das Entwickeln von WordPress Themes und Plugins für Inpsyde. Außerdem hat er das Buch "WordPress für Entwickler" verfasst.

Latest posts by David Remer (see all)