Verwenden von WordPress-Hooks zum Bereinigen von Code, Aktivieren und Deinstallieren
Veröffentlicht: 2015-01-23Plugin-Autoren widmen der Hauptfunktionalität ihrer Produkte so viel Zeit und Energie, dass sie weniger wichtige Dinge auf der Strecke lassen.
Nehmen Sie zum Beispiel die Aktivierung und Deaktivierung. Während Aktivierungs-Hooks weit verbreitet sind – viele Plugins müssen einige Optionen hinzufügen, Rewrite-Regeln löschen, vielleicht eine Datenbanktabelle erstellen oder bei der Installation nach Versionsunterschieden suchen – sind Deaktivierungs- und Deinstallations-Hooks weitaus seltener.
Der Punkt hier? Viele Plugin-Autoren nehmen sich nicht die Zeit, hinter sich aufzuräumen. Benötigt die WordPress-Installation wirklich die benutzerdefinierte Tabelle, die Sie nach dem Entfernen des Plugins erstellt haben? Warum nicht ein paar Optionen löschen, die exklusiv für das Plugin sind, bevor Sie es löschen?
In diesem Artikel zeige ich Ihnen, wie Sie Aktivierungs-, Deaktivierungs- und Deinstallations-Hooks verwenden, um Ihr Plugin zu initialisieren und Dinge einfacher zu bereinigen, nachdem Benutzer mit Ihrem Produkt fertig sind.
- Der Aktivierungshaken
- Die Installationssequenz
- Flush-Rewrite-Regeln
- Erstellen von Datenbanktabellen
- Abhängigkeitsprüfungen
- Der Deaktivierungshaken
- Der Deinstallations-Hook
- Zusätzliche Sicherheit
- Es ist Zeit aufzuräumen
Hinweis: Wenn Sie vorhaben, diesen Artikel zu überfliegen, empfehle ich dringend, einen Blick auf den Abschnitt „Zusätzliche Sicherheit“ am Ende zu werfen, der den Code mit einigen wertvollen Sicherheitsüberprüfungen ergänzt. Wenn Sie Hilfe mit WordPress-Plugin-Hooks benötigen, finden Sie hier eine kurze Auffrischung zur Verwendung von WordPress-Hooks und zur Aktivierung einer Funktion in WordPress.
Der Aktivierungshaken
Obwohl der Aktivierungs-Hook recht einfach ist, ist seine Installation ein kleiner Sonderfall, daher müssen wir auf die Abfolge der Ereignisse achten. Bevor wir auf all das eingehen, hier ein einfaches Beispiel:
Der Schlüssel zu allem ist die Funktion register_activation_hook() . Der erste Parameter ist der Pfad zur Haupt-Plugin-Datei; der zweite Parameter definiert die auszuführende Funktion. Intern ist die Funktion register_activation_hook() ein Wrapper für die Aktion „activate_[plugin_name]“, aber da sie etwas einfacher zu verwenden ist, ist es ungewöhnlich, den Hook in Plugins zu sehen.
Die Installationssequenz
Es ist wichtig, die Installationssequenz zu verstehen, da dies die Verwendung von Methoden verhindert, an die Sie möglicherweise gewöhnt sind. register_activation_hook() wird zwischen dem Klicken des Benutzers auf den Aktivierungslink und dem anschließenden Anzeigen des Aktivierungshinweises aufgerufen. Es wird auf einer Zwischenseite ausgeführt, die unmittelbar umleitet, bevor Hooks ausgeführt werden können.
Schauen wir uns ein Beispiel an, um zu sehen, warum dies ein großer Mist ist:
Flush-Rewrite-Regeln
Eine Reihe von Plugins erstellen benutzerdefinierte Beitragstypen. Das Leeren der Rewrite-Regeln bei der Aktivierung, um sicherzustellen, dass Benutzer keinen 404-Fehler erhalten, wenn sie einen Beitrag des neuen benutzerdefinierten Beitragstyps besuchen, ist ein kluger Schachzug.
Der folgende Code erscheint logisch, wird aber fehlschlagen.
Es scheint vollkommen in Ordnung zu sein. Der benutzerdefinierte Beitragstyp wird erstellt und bei der Aktivierung löschen wir die Umschreibungsregeln. Das Problem ist, dass die benutzerdefinierten Post-Typen noch nicht erstellt wurden, wenn wir die Rewrite-Regeln löschen.
So sieht der Prozessablauf aus:
- Der Benutzer installiert das Plugin.
- Der Benutzer klickt auf den Aktivierungslink.
- Eine Zwischenseite führt nur den Aktivierungs-Hook aus, sonst nichts. Dadurch werden die Rewrite-Regeln geleert.
- Das Plugin ist aktiv und der Code wird wie gewohnt ausgeführt. Der benutzerdefinierte Beitragstyp ist registriert.
Eine auf Stack Overflow gepostete Lösung, die offiziell vom WordPress Codex unterstützt wird, löst unser kleines Problem. Die Lösung besteht darin, eine Option hinzuzufügen, die anzeigt, dass das Plugin gerade installiert wurde.
Wenn diese Option vorhanden ist, erledigen wir unsere Aktivierungssachen und löschen sie dann.
Etwas wie das:
Mir persönlich gefällt diese Lösung nicht so gut. Das Problem ist, dass die Prüfung in Zeile acht bei jedem einzelnen Seitenladevorgang ausgeführt wird. Es ist kein Grund zur Sorge, da es Ihre Server nicht stark belastet und die Website für Ihre Benutzer nicht verlangsamt. Dies ist eine sehr schnelle Überprüfung mit vernachlässigbarer Auswirkung auf die Leistung. Es ist jedoch zu 99,9 % der Zeit unnötig.
Es gibt eine bessere Lösung, die im Codex in der Dokumentation für die Funktion flush_rewrite_rules() erwähnt wird. In dieser Lösung nutzen wir die Modularität unserer Funktionen, um den benutzerdefinierten Beitragstyp bei der Aktivierung separat zu registrieren:
Anstatt sich auf eine Prüfung zu verlassen, die ständig ausgeführt werden muss, verwenden wir die Aktivierungsfunktion, um unsere Posttypen zu registrieren. Beachten Sie, dass sobald unser Plugin aktiviert ist, die Beitragstypen immer vom init Hook registriert werden.
Dies ist ein trauriges Beispiel dafür, dass der Kodex überall herumliegt. Im Allgemeinen hat WordPress eine gute Dokumentation, aber wenn etwas verschwenderisch oder unlogisch erscheint, haben Sie keine Angst, selbst zu recherchieren.
Erstellen von Datenbanktabellen
Eine weitere Aufgabe, die einige Plugins ausführen, ist das Erstellen von Datenbanktabellen. Meistens ist dies unnötig, aber es gibt einige legitime Anwendungsfälle.
Dieses Beispiel aus dem Codex-Artikel zum Erstellen von Tabellen zeigt, wie mehrere Aktivierungsaufrufe verwendet werden können:
Die erste Funktion jal_install() erstellt eine neue Datenbanktabelle. Die zweite Funktion jal_install_data fügt der Tabelle Anfangsdaten hinzu. Anstatt register_activation_hook() zu verwenden, um eine Funktion hinzuzufügen, die den gesamten Code enthält, können wir register_activation_hook mehrmals verwenden.
Dies ist eine großartige Praxis für Modularität. Einerseits müssen Sie keine ersten Testdaten hinzufügen – es ist so einfach wie das Entfernen des Aktivierungshakens –, sodass Sie die Funktion intakt halten können. Andererseits können Sie diese Funktionen überall wiederverwenden, da sie separat sind.
Abhängigkeitsprüfungen
Eine weitere häufige Aufgabe für die Aktivierungsfunktion ist die Prüfung auf Abhängigkeiten. Ihr Plugin kann auf einer bestimmten Version von WordPress, einem anderen Plugin oder sogar einer bestimmten Version von PHP basieren.
Der folgende Code prüft auf eine minimale WP- und PHP-Version und leitet den Benutzer gegebenenfalls um (ohne das Plugin zu aktivieren):
Der Deaktivierungshaken
Deaktivierungs-Hooks werden ausgeführt, wenn ein Benutzer ein Plugin deaktiviert hat, aber bevor es deinstalliert (gelöscht) wird. Deaktivierungshaken werden auf die gleiche Weise wie Aktivierungshaken verwendet:
Deaktivierung bedeutet, dass der Benutzer Ihr Plugin nur deaktiviert hat, sodass Sie nicht so viel tun möchten, wie Sie es bei einer Deinstallation tun würden. Vielleicht möchten Sie Rewrite-Regeln löschen, aber zu diesem Zeitpunkt möchten Sie nicht alle Ihre Optionen und Ihre Datenbanktabelle (falls vorhanden) loswerden.
Dies ist ziemlich einfach, aber ich werde besonderes Augenmerk auf das Löschen von Umschreibregeln legen, da diese wiederum problematisch sind.
Der Kodex empfiehlt, sie wie unten gezeigt zu machen, aber das funktioniert nicht :
Der Grund, warum dies nicht funktioniert, ist derselbe wie zuvor. Das Ausführen einer Deaktivierung führt den init Hook aus, was bedeutet, dass wir beim Deaktivieren unseres Plugins auch unseren benutzerdefinierten Beitragstyp registrieren. Die Rewrite-Regeln werden geleert, berücksichtigen aber den benutzerdefinierten Beitragstyp.
Ein Trac-Ticket ist vorhanden, um dies anzugehen, aber bis dahin kann ich Ihnen keine sehr gute Möglichkeit geben, dies zu tun. Die einzige Möglichkeit, die ich gefunden habe, besteht darin, die Umschreibungsregeln vollständig zu löschen:
Obwohl dies in der Vergangenheit für mich funktioniert hat, würde ich es nicht empfehlen. Es führt zu einer größeren Unsicherheit als das Problem, ein paar zusätzliche Neuschreibregeln zu haben. Ich würde den Benutzern lieber einen Hinweis anzeigen, der sie auffordert, nach der Deaktivierung die Permalink-Einstellungen zu besuchen, wodurch die Umschreibungsregeln geleert würden. Bis eine bessere Lösung implementiert ist, bleiben wir dabei … Entschuldigung!
Der Deinstallations-Hook
Es gibt zwei Möglichkeiten, Code auszuführen, wenn ein Plugin deinstalliert wird. Sie können den Deinstallations-Hook über register_uninstall_hook() verwenden oder Sie können eine dedizierte uninstall.php -Datei in Ihrem Plugin verwenden. Ich werde Ihnen beide zeigen, aber die bevorzugte Methode ist die Verwendung der Deinstallationsdatei.
Das Hauptproblem mit dem Deinstallations-Hook ist, dass „es verhindert, dass die Haupt-Plugin-Datei während der Deinstallation ausgeführt wird, was problematisch sein kann, wenn das Plugin Code im globalen Raum ausführt. Es ist auch insofern besser, als der Deinstallationscode zentralisiert ist.“ – Scott Riley
Der folgende Code zeigt den Deinstallationsprozess mit einem einfachen Hook:
Wie gesagt, das ist nicht die beste Lösung. Ein weitaus besserer Weg, Deinstallationen zu handhaben, ist die Verwendung der Datei uninstall.php . Alles, was Sie tun müssen, ist es zu erstellen und es wird verwendet, wenn es verfügbar ist.
Wie Sie sehen können, ist dies eigentlich eine einfachere Lösung. Das Beste daran ist, dass es in sich geschlossen ist.
Zusätzliche Sicherheit
Ich wollte die bisher gezeigten Beispiele nicht mit sicherheitsrelevanten Themen überkomplizieren, aber Sie sollten wirklich einige Schritte unternehmen, um sicherzustellen, dass nur diejenigen, die dazu berechtigt sind, diese Aktionen ausführen können.
Verwenden Sie das folgende Snippet zur Aktivierung und Deaktivierung:
Dieser Codeblock stellt sicher, dass der Benutzer die Berechtigungen zum Ausführen dieser Aktion hat und dass die Aktion von der richtigen Seite ausgeht. Dies sollte vor den meisten böswilligen Versuchen schützen.
Der Deinstallationsprozess ist etwas Besonderes, daher müssen wir etwas anderen Code verwenden:
Es ist Zeit aufzuräumen
Wenn dein Plugin WordPress etwas hinzufügt, dann ist es deine Pflicht als Entwickler, es zu entfernen, wenn ein Benutzer beschließt, dein Plugin zu löschen.
Mit den oben beschriebenen Aktivierungs-, Deaktivierungs- und Deinstallationsmethoden können Sie ein System aufbauen, das dies sicher und zuverlässig durchführt. Ich empfehle auch dringend, diesen Stackexchange-Thread zu lesen, der diese Prozesse in OOP-Umgebungen umreißt.
Wenn Sie noch kein WPMU DEV-Mitglied sind, melden Sie sich noch heute für eine kostenlose Testversion an, völlig risikofrei. Als Mitglied erhalten Sie Zugriff auf alle unsere großartigen Plugins und einen blitzschnellen Hosting-Service sowie Experten-Support rund um die Uhr für alle Ihre WordPress-bezogenen Fragen und Probleme.
Stichworte: