Child Plugins: Actions in Plugins finden oder selbst einbauen

Im letzten Beitrag habe ich euch eine kleine Einführung in der Welt des WordPress Hook Systems gegeben und euch dabei auch zwei kleine Beispiele gegeben. Beide konnte ich aus der Dokumentation des Plugins entnehmen. Wie genau werden solche Hook aber eingebaut und wie kann man diese dann erkennen? Genau das möchte ich euch im heutigen Artikel kurz erklären.

Action-Hooks in Plugins finden

Was macht man also, wenn es keine Dokumentation gibt, man aber trotzdem an einem Plugin Veränderungen vornehmen möchte. Ein Weg wäre es natürlich, nach der Problemstellung in einer Suchmaschine oder auf Portalen wie WordPress StackExchange danach zu suchen.

Ich schaue aber meistens direkt im Code nach, ob ich einen passenden Hook finde, an dem ich ansetzen kann. Im Fall von

Actions mit Ausgabe

Ein Action-Hook wird im Code über die Funktion do_action() bereitgestellt. Im letzten Artikel haben wir ja bereits gelernt, dass diese in der Regel Code ausgeben oder andere Seiteneffekt ausführen. Oftmals werden sie daher also wie folgt verwendet:

class WPSEO_Metabox_Addon_Tab_Section extends WPSEO_Metabox_Tab_Section {

	public function display_content() {
		?>
		<div id="wpseo-meta-section-addons" class="wpseo-meta-section">
			<div class="wpseo-metabox-tabs-div" >
				<ul class="wpseo-metabox-tabs" id="wpseo-metabox-tabs">
					<?php do_action( 'wpseo_tab_header' ); ?>
				</ul>
			</div>
			<?php do_action( 'wpseo_tab_content' ); ?>
		</div>
	<?php
	}
	// ...
}

Das Beispiel zeigt eine Klasse des Yoast SEO Plugins, das es anderen Plugin-Autoren ermöglicht, zusätzliche Metabox-Tabs hinzuzufügen. Dazu hängen sie sich in die beiden Actions wpseo_tab_header und wpseo_tab_content um die Tabs-Beschriftung und den Inhalt zu setzen. Dabei ist also klar, dass sie den Code per echo ausgeben müssen.

Actions in Prozessen

Action werden aber auch oft in Prozessen eingesetzt, damit man die Möglichkeit hat während eines Prozesses, bzw. davor oder danach, eine Aktion auszuführen. Hier ein einfaches Beispiel um dies zu zeigen:

class WPCF7_ContactForm {
	
	// ...
	
	public function save() {
		
		// ...
		
		if ( $post_id ) {
		
			// ...

			if ( $this->initial() ) {
				$this->id = $post_id;
				do_action( 'wpcf7_after_create', $this );
			} else {
				do_action( 'wpcf7_after_update', $this );
			}

			do_action( 'wpcf7_after_save', $this );
		}

		return $post_id;
	}
	
	// ...
}

In diesem Beispiel sehen wir die Funktion des Contact Form 7 Plugins, die für die Speicherung und Aktualisieren von neuen Formularen zuständig ist. Hier werden nach dem Speichern des Formulars drei Actions angeboten, die ein Entwickler nun nutzen könnte, um nach dem Anlegen eines neuen Formulars, der Aktualisierung eines bestehenden oder immer nach dem Speichern ausführen könnte. Alle drei Actions werden vom Contact Form 7 Plugin nicht selbst verwendet.

Parameter an Actions übergeben

Der Funktion wird in diesem Fall das aktuelle WPCF7_ContactForm Objekt ($this) übergeben. Der Entwickler, der die Action nutzt, kann also mit diesem Objekt innerhalb der Callback-Funktion arbeiten. Möchte man nun eine Callback-Funktion auf diese Action schreiben, dann ist es wichtig, dass man bei der Deklaration der Funktion diesen Parameter auch mit angibt:

function custom_action_wpcf7_after_save( WPCF7_ContactForm $contact_form ) {
	// Use the object, e.g. getting the config errors.
	$config_errors = $contact_form->get_config_errors();
	// Do something with the $config_errors variable.
}
add_action( 'wpcf7_after_save', 'custom_action_wpcf7_after_save', 10, 1 );

Die Deklaration sieht aus wie im Beispiel im vorherigen Artikel. Neu sind allerdings die Parameter 3 und 4 beim Registrieren der Callback-Funktion mit der add_action() Methode. Der dritte Parameter gibt die Priorität an und der vierte die Anzahl der Parameter, die an die Callback-Funktion übergeben werden.

Eigentlich habe ich hier etwas geschrieben, das gar nicht notwendig ist. Denn sowohl die Priorität von 10, als auch die Parameteranzahl von 1 sind jeweils die Standardwerte. Man müsste sie also erst dann zwingend angeben, wenn die Parameteranzahl größer als 1 ist (oder man die Priorität ändern möchte). Aber wieso nicht sauber arbeiten und sie trotzdem angeben? 🙂

In diesem Beispiel verwende ich übrigens auch ein sogenanntes „type hinting“. Ich gebe also an, dass es sich bei der Variablen $contact_form um ein WPCF7_ContactForm Objekt handelt. Dies ist nicht zwingend notwendig, hilft aber einer IDE beim Programmieren, die Eigenschaften und Funktionen des Objekts zu erkennen und vorzuschlagen.

Actions in eigenen Plugins anbieten

Ihr habt hoffentlich das System hinter den Actions durch die Beispiele besser verstehen können. Wenn ihr nun selbst Plugin-Entwickler seid und eure Plugins erweiterbar machen wollt, dann überlegt am besten, an welchen Stellen ein anderer Entwickler eventuell Anpassungen machen möchte. Gerade in Template-Dateien macht es durchaus Sinn, vor und nach einem größeren HTML-Block jeweils einen Action-Hook einzubauen. Damit könnte ein anderer Entwickler euren HTML-Code z.B. in einen zusätzlichen Container packen und diesen stylen.

Action-Hooks für Prozesse sind an solchen Stellen sehr sinnvoll, an denen euer Plugin Daten erzeugt oder ändert bzw. an denen es Fehler erkennt, auf die dann über einen solchen Action-Hook reagiert werden kann.

Ich habe in meinen Plugins selbst auch eher wenige Action-Hooks von vornherein eingebaut. Meistens wurde ich durch einen anderen Entwickler darauf aufmerksam gemacht, dass an einer bestimmten Stelle ein Hook helfen könnte. Also seid offen für solche Anregungen.

Fazit

Ich hoffe nach dem Lesen dieses Artikels habt ihr nun ein Gefühl dafür bekommen, wie man Actions im Code eine Plugins finden kann, wie man sie einsetzt und wie man als Entwickler eigene anbieten kann. Da dies schon wieder sehr viele Informationen waren, die ihr erst einmal verarbeiten solltest, werde ich erst im nächsten Artikel in einer Woche auf die Filter-Hooks eingeben und ähnlich zu den Actions-Hooks Anwendungsfälle zeigen. Dann gibt es garantiert auch mal Callback-Funktionen mit mehr als einem Parameter 🙂

P.S. Hatte ich eigentlich schon erwähnt, dass dies mein 200. Artikel in meinen deutschsprachigen Blog war? Nein? Na dann wisst ihr es ja jetzt. Die ersten 100 Artikel hatte ich übrigens schon nach zwei Jahren voll. Aber mehr hierzu in ein paar Tagen 😉

Weitere Artikel zu Themenreihe

Dies ist der dritte Teil der Themenreihe „Child Plugins“. Hier findest du die anderen Beiträge:

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugin, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.