Datenschutz und Optimierung eines WordPress-Dashboard-Widget

Was Sie erstellen werden

In den ersten beiden Teilen dieser Serie haben wir ein voll funktionsfähiges Plugin fertiggestellt, das uns den Serverstatus als Dashboard-Widget zeigt. Als solches steht es jedem angemeldeten Benutzer zur Verfügung. Einige Informationen können vertraulich sein, und wir möchten nicht, dass diese Informationen angezeigt werden. Es ist daher besser, die Benutzerrolle zu prüfen, um festzustellen, ob das Widget für sie verfügbar ist.

Verwenden von Rollen oder Funktionen zum Begrenzen der Sichtbarkeit

WordPress verwendet ein Rollenkonzept, das dem Websitebesitzer die Möglichkeit gibt zu steuern, was Benutzer innerhalb der Site tun können und was nicht. Jede Rolle kann eine Reihe von Aufgaben ausführen, die als Funktionen bezeichnet werden. Wir können die Rolle und ihre Funktionen mit den Funktionen add_roles und add_cap anpassen.

Unser Plugin erstellt einen neuen Funktionsaufruf servermetrisch. Nur der Benutzer mit dieser Funktion kann unsere Dashboard-Widgets laden. Wir werden diese Funktion für die Administratorrolle hinzufügen, sodass alle Administratorbenutzer dies standardmäßig sehen können.

Für die anderen Benutzer können Sie den Plug-In-Benutzerrollen-Editor verwenden, um die Funktionen eines bestimmten Benutzers zu verwalten und das zuzuweisen servermetisch Fähigkeit für den Benutzer.

Wir verwenden add_cap, um eine neue Funktion hinzuzufügen. Diese Funktion schreibt jedoch in die Datenbank. Daher sollten wir dies nur tun, wenn das Plugin aktiviert wird. Nach der Deaktivierung sollten Sie die Datenbank bereinigen, indem Sie die Rolle mit remove_cap entfernen.

Klasse Dashboard //… anderer Code const CAP_METRIC = 'server_metric'; / ** * Start zum Einrichten des Hooks * / public function run () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ this, 'add_asset')); add_action ('admin_footer', array ($ this, 'footer'))); register_activation_hook (__ FILE__, array ($ this, 'add_servermetric_caps')); register_deactivation_hook (__ FILE__, array ($ this, 'remove_servermetric_caps'));  / ** * Fügt dem Administrator standardmäßig mehrere Funktionen hinzu. * / Function add_servermetric_caps () // ruft die Autorenrolle ab $ role = get_role ('administrator'); // Das funktioniert nur, weil auf die Klasseninstanz zugegriffen wird. // würde es dem Autor ermöglichen, die Beiträge anderer nur für das aktuelle Thema zu bearbeiten $ role-> add_cap (self :: CAP_METRIC);  function remove_servermetric_caps () // get_role gibt eine Instanz von WP_Role zurück. $ role = get_role ('administrator'); $ role-> remove_cap (self :: CAP_METRIC);  //…

Wir erstellen einen neuen ständigen Anruf CAP_METRIC und setze seinen Wert auf server_metric So können wir den Namen der Fähigkeit später leicht ändern. Wir modifizieren unsere Lauf Methode, um zwei Haken hinzuzufügen.

Der register_activation_hook wird ausgeführt, wenn das Plugin aktiviert wird. Es akzeptiert zwei Parameter:

(String) Dateiname: Pfad zur Haupt-Plugin-Datei
(Ruf zurück) (erforderlich) Die Funktion, die ausgeführt werden soll, wenn das Plugin aktiviert ist

register_deactivation_hook wird beim Deaktivieren des Plugins ausgeführt. Es akzeptiert dieselben Parameter wie register_activation_hook.

Innerhalb jeder Hook-Funktion laden wir die Rolle Administrator und Ruf an add_cap oder remove_cap auf dem Rollenobjekt.

Als nächstes werden wir unsere ändern add_dashboard_widgets Methode, um die Widgets nur zu registrieren, wenn der aktuelle Benutzer die servermetrisch Deckel.

 / ** * Registrieren Sie den Dashboard-Widget-Proider, um ihn im Dashboard anzuzeigen * / function add_dashboard_widgets () if (! Current_user_can (self :: CAP_METRIC)) return false;  $ widget = Widget :: instance (); foreach ($ widget-> get_provider () als $ name => $ provider) $ widget-> register ($ name);

Als Nächstes verwenden wir current_user_can, um zu prüfen, ob der aktuelle Benutzer über die Anforderungsfunktion verfügt.
Jetzt wird das Widget nur vom Administrator angezeigt, wenn das Dashboard geladen wird. Wenn Sie das Serverstatus-Widget für andere Benutzer aktivieren möchten, können Sie den Plug-In-Benutzerrollen-Editor installieren, um Rollen und Funktionen für beliebige Benutzer zu verwalten.
Nach der Installation und Aktivierung gehen Sie zum Menü Benutzer und wählen Sie die Option Benutzer> Fähigkeiten:

Dann können wir auf dem Fähigkeitenbildschirm die server_metric Deckel.

Bearbeiten Sie die Benutzerfunktionen mit dem Plugin für Benutzerrollen-Editor

Durch die Nutzung von Rollen und Funktionen haben wir die Plug-In-Sicherheit verbessert, sodass unser Widget nur Nutzern zugänglich ist, denen wir vertrauen.

Zwischenspeicherung der Server-Metrik

WordPress verwendet die Transients-API als Cache-API. Die Daten werden serialisiert und im gespeichert wp_option Tabelle von WordPress mit einer Ablaufzeit des Cache.

Anstatt Metrikdaten für jede HTTP-Anforderung abzurufen, können wir die Daten einmal abrufen und im Cache speichern. Wir können jedoch nicht einfach alles in den Cache legen oder die gleiche Ablaufzeit verwenden. Beispielsweise kann der Festplattenspeicher für 15 Minuten zwischengespeichert werden, und Serverinformationen können für 60 Minuten zwischengespeichert werden, da sie sich selten ändern. In ähnlicher Weise kann installierte Software für einen Tag zwischengespeichert werden, da sie sich kaum ändert, sobald der Server eingerichtet und für die Produktion bereitgestellt wird.

Wir benutzen meistens get_transient und set_transient beim Arbeiten mit der API. Laut der WordPress-Dokumentation:

get_transient ($ transient): Ruft den Namen des Transienten als Zeichenfolge ab und gibt seine Daten zurück. Wenn die Daten abgelaufen sind, wird false zurückgegeben. Wir sollten ... benutzen === Operator zu überprüfen, da wir einen leeren Wert für den Übergang speichern können.
set_transient ($ transient, $ value, $ expiration): ruft drei Parameter ab: den Namen des Transienten, seinen Wert und die Ablaufzeit in Sekunden. Beachten Sie, dass der Transientenname nicht länger als 45 Zeichen sein darf.

Wir haben zwei Möglichkeiten, die Metrikdaten zu speichern oder die generierten HTML-Daten zu zwischenspeichern. Das Zwischenspeichern der HTML-Daten kann unsere Website sehr schnell machen, belastet jedoch die Datenbank. Zu diesem Zweck könnten wir Benchmarks durchführen, um zu entscheiden, welches das Beste ist.

Lassen Sie uns für unser Tutorial die Metrikdaten zwischenspeichern. Außerdem sollte es möglich sein, den Cache - wie einen Anker - für ungültig zu erklären, wodurch wir die Dashboard-Daten erneut laden und das Laden der Daten erzwingen können, anstatt sie aus dem Cache zu laden.

Daten für das Widget zwischenspeichern

Wir können die Funktion direkt nutzen get_transient oder set_transient um mit Transient API zu arbeiten. Wenn wir uns jedoch dazu entschließen, die Art und Weise, wie wir die Transient-API verwenden, zu ändern, müssen wir jeden Ort, an dem wir es verwenden, durchgehen und es für jedes Widget ändern.

Fügen Sie eine weitere Ebene hinzu, um den Cache-Mechanismus zu abstrahieren. Wir werden eine einfache Cache-Klasse für unser Widget entwerfen, die drei Methoden hat:

einstellen: Cache-Daten für ein Widget festlegen
erhalten: Cache-Daten für ein Widget abrufen
Belastung: Versuchen Sie, aus dem Cache zu laden, falls nicht vorhanden, berechnen Sie die Daten, setzen Sie den Cache und kehren Sie zurück

Lassen Sie uns die Datei zusammenstellen widget / cache.php auf die folgende Weise. Beachten Sie, dass der Klassenname gemäß unserer automatischen Ladekonvention lautet Zwischenspeicher und sein Namensraum ist AX \ StatBoard \ Widget

get_metric (); static :: set ($ provider, $ data, $ cache_time); $ data zurückgeben;

Beachten Sie zunächst, dass wir unsere Caching-Methoden als statisch markiert haben. Unsere einstellen und erhalten Methoden sind nur Wrapper für get_transient und set_transient. Das Belastung Methode sitzt oben auf einstellen und erhalten. Alle diese Methoden erwarten, dass das Widget-Provider-Objekt abgerufen wird. daher innerhalb von Belastung Methode, die wir aufrufen können get_metric Methode, um die realen Daten zu erhalten.
Das Wichtigste ist hier der vorübergehende Name. Da der Klassenname innerhalb unserer Anwendung eindeutig ist, betrachten wir ihn als eindeutig genug für den vorübergehenden Namen. Die Funktion get_class gibt den Klassennamen eines Objekts zurück.
Zeit für die Nutzung unserer Zwischenspeicher Klasse. Wir werden versuchen zu implementieren Zwischenspeicher zum widget / software.php. Ändern Sie unser Original get_content Methode zu:

$ info) $ content. = "$ cmd  $ info
"; echo $ content; //…

Sie können sehen, dass wir loswerden $ cmds = $ this-> get_metric () und ersetzen Sie es einfach mit Cache :: load Dadurch werden Daten aus dem Cache oder vom System geladen, wenn kein Cache vorhanden ist.
Stellen Sie sicher, dass Sie den zweiten Parameter übergeben, wie lange die Daten zwischengespeichert werden sollen. Andernfalls werden die Daten nur fünf Minuten zwischengespeichert. Da sich Software-Informationen auf dem Server kurzfristig nur selten ändern, setzen wir die Cache-Zeit auf 24 Stunden.
Nun, da Sie die Idee haben, können Sie es mit jedem anderen Widget wiederholen, das Sie zwischenspeichern möchten. Einfach austauschen get_metric Innerhalb get_content mit:

Cache :: load ($ this, $ time_in_second);

um es für seine Zwischenspeicherung sorgen zu lassen.
Die Daten der Datenträgernutzung können für Stunden zwischengespeichert werden, und die Ethernet-Schnittstelle kann für einen Tag im Cache gespeichert werden. Sie entscheiden selbst, wie lange Sie es zwischenspeichern möchten. Wir können auch eine Optionsseite für das Plugin erstellen, um diesen lebenslangen Cache-Wert zu verwalten. Das kann eine Übung sein, an der Sie arbeiten können, nachdem wir diesen Artikel fertiggestellt haben.
Wir haben ein letztes Beispiel mit widget / ethernet.php. Wir können die Cache-Fähigkeit wie folgt hinzufügen:

öffentliche Funktion get_content () 
$ schnittstellen = Cache :: load ($ this, 3600 * 24 * 7);
$ html = '


';
foreach ($ schnittstellen als $ interface => $ ip) 
$ html. = "


";

$ html. = 'Schnittstelle IP
$ interface $ ip
';
echo $ html;

  //…

Schnittstelle	IP
$ interface	$ ip

Wieder müssen wir nur ersetzen get_metric mit Cache :: load. Die Ethernet-Informationen und ihre IP-Adresse ändern sich wahrscheinlich nie. Daher habe ich eine sehr lange Cache-Lebensdauer von einer Woche festgelegt: 3600 Sekunden * 24 Stunden * 7 Tage.

Laden von realen Daten erzwingen

Sobald wir eine Cache-Funktion hinzugefügt haben, sollten wir einen Mechanismus unterstützen, damit der Administrator das Widget ziehen kann, ohne dass es zwischengespeichert wird. Am einfachsten ist es, einen speziellen Abfrageparameter zu verwenden, um anzuzeigen, dass wir echte Daten wünschen.

Wie wäre es mit kleinen Parametern? Nocache dafür? Also anstelle der Standard-WordPress-Dashboard-URL mit domain.com/wp-admin/ wir können benutzen domain.com/wp-admin/?nocache.

Klingt einfach? Machen wir das.

Bearbeiten Sie unsere Methode erhalten in widget / cache.php

 statische Funktion get (Provider $ provider) if (isset ($ _ GET ['nocache'])) return false;  $ cache_id = get_class ($ provider); if (false! == $ data = get_transient ($ cache_id)) return $ data;  falsch zurückgeben;

Solange die Nocache Abfrageparameter vorhanden, geben wir sofort false zurück und zwingen daher, dass die tatsächlichen Daten anstelle der zwischengespeicherten Daten abgerufen werden.
Lassen Sie uns nun darüber nachdenken, diese Funktion ohne die Cache-Klasse hinzuzufügen. Wir müssen möglicherweise zu jeder Zeile von get_transient und dort nach dem Abfrageparameter suchen. Berücksichtigen Sie daher beim Entwerfen Ihres Plugins die Unterteilung in mehrere Ebenen. Fügen Sie nicht alles in dieselbe Datei ein oder kopieren Sie den Einfügecode immer wieder.
Lass uns versuchen zu besuchen domain.com/wp-admin und domain.com/wp-admin?nocache und bemerke die unterschiedliche Geschwindigkeit.

987ms Laden mit Cache-Freigabe

Hier ist das Ergebnis mit ?nocache = 1 an die URL angehängt.

3.01 Sekunden Laden ohne Cache

Mit cronjob Cache generieren

Obwohl wir einen Cache implementiert und verwendet haben, ist die Seite immer noch langsam, wenn der Cache fehlt. Es dauert immer noch Zeit, um Daten vom Server abzurufen. Mit Cronjob haben wir noch viel zu verbessern. Wir können festlegen, dass unser Plugin in einem bestimmten Intervall ausgeführt wird. WordPress ermöglicht dies über wp_schedule_event. Idealerweise können wir verwenden wp_schedule_event um einen Hook zu planen, der in einem bestimmten Intervall ausgeführt wird.

Wenn Sie dieses Beispiel betrachten, kann unser Plugin alle drei Minuten einen Hook zum Aufrufen planen. Der Hook ruft eine andere Funktion auf, um die Metrikdaten abzurufen. Die Daten sind immer im Cache verfügbar und frisch genug.

Öffnen Sie unsere Haupt-Plugin-Datei, serverdashboard.php, und aktualisieren Sie die Run-Methode, um neue Hooks sowie neue Hook-Handler aufzunehmen.

 3 * 60, 'Anzeige' => __ ('Alle 3 Minuten')); $ Zeitpläne zurückgeben;  / ** * Einstellungszeitplan für das Ereignis. Wenn der Zeitplan nicht existiert, registrieren wir ihn bei * / function setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (time (), '3min', 'metric_generate_every_3min');  / ** * Die Hauptfunktion, die auf cron ausgeführt wird und * Daten erzeugen * / function generate_metric () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () als $ name => $ provider) // Durch Aufruf von get_content lösen wir den Cache :: load-Prozess aus. $ provider-> get_content ();

Erstens unterstützt die Methode wp_schedule_event nur drei Wiederholungstypen: täglich, stündlich und zweimal täglich. Wir müssen eine neue Art der Wiederholung mit dem Filter wp_get_schedules hinzufügen.
Wir fügen einen weiteren wiederkehrenden Typ hinzu, der alle drei Minuten ausgeführt wird. Seine Definition:

 $ schedule ['3min'] = Array ('Intervall' => 3 * 60, 'Anzeige' => __ ('Alle 3 Minuten')); $ Zeitpläne zurückgeben;

Wir können den Intervallwert so anpassen, wie viele Sekunden der Auftrag wiederholt werden soll. Als nächstes richten wir ein metric_generate_every_3min Haken.

 add_action ('metric_generate_every_3min', array ($ this, 'generate_metric'));

Dies ist unser benutzerdefinierter Hook, er existiert nicht in WordPress. Wir registrieren einen Handle mit Methode generate_metric für diesen Haken. Wann auch immer metric_generate_every_3min Hook wird aufgerufen, generate_metric wird durchgeführt.
In der nächsten Aussage haken wir uns in Aktion drin mit setup_schedule Methode, um zu prüfen, ob das nächste geplante Ereignis des Hooks vorhanden ist metric_generate_every_3min. Wenn es noch nicht definiert ist, planen wir ein Ereignis mit wp_schedule_event, Verwenden Sie unsere benutzerdefinierte Wiederholung alle drei Minuten für diesen Haken.
In der generate_metric Methode durchlaufen wir alle verfügbaren Widget-Angebote und rufen sie an get_content Methode. Dadurch lösen wir aus Cache :: load Prozess für diese Metrik.
WordPress führt diese geplanten Ereignisse automatisch aus, wenn jemand Ihre WordPress-Site besucht. Es wird versucht, das geplante Ereignis zu finden, das ausgeführt werden muss, und es aufzurufen.
Sie können sie jedoch auch manuell ausführen. WordPress führt Cronjob über den Besuch der Datei aus wp-content.php mit der URL yourdomain.com/wp-cron.php?doing_wp_cron.
Möglicherweise möchten Sie Ihren Cronjob aktualisieren, um einen neuen Job hinzuzufügen, der alle Minuten die obige URL anpingt
Lassen Sie uns Ihre Crontab auf dem Server mit öffnen Crontab -e und füge diese Zeile am Ende hinzu:

0 * * * * wget domain.com/wp-cron.php?doing_wp_cron> / dev / null 2> & 1

Wir haben wget verwendet, um eine HTTP-Anforderung an die Datei wp-cron.php zu senden. Da uns die Ausgabe und Fehler nicht interessieren, leiten wir die gesamte Ausgabe zu um / dev / null.
Weitere Informationen zum Einrichten dieser Cronjobs finden Sie in den folgenden Artikeln:

http://tommcfarlin.com/wordpress-cron-jobs/
http://code.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordp…

Fazit

Damit ist unser langes Tutorial zum Erstellen eines Server-Dashboard-Widgets abgeschlossen, das Einblicke in verschiedene Aspekte unseres Systems bietet.
In dieser Serie haben wir Bibliotheken von Drittanbietern verwendet, eine Idee entwickelt, mit der Befehlszeile experimentiert, etwas über Rollen und Fähigkeiten erfahren und die Transient-Funktionen von WordPress sowie die Mechanismen für die Ereignisplanung überprüft.
Zum Schluss haben wir alles in einem WordPress-Plugin zusammengefügt.
Bitte überlegen Sie, einen Kommentar zu hinterlassen, und lassen Sie uns wissen, welche zusätzlichen Ideen und Änderungen Sie mitbringen und welche Fragen und / oder Kommentare Sie zu dieser Serie haben.

Code