Durch die aktuelle Arbeit am Plugin Adminimize sind mir wieder einige Punkte aufgefallen, die ich sinnvoll finde und in Plugins integriere.
Es ist Mehrwert, der sich aber zum Standard für Plugin-Autoren entwickeln sollte und daher lege ich es mal mit kurzer Erläuterung hier ab. Drei Lösungen sollen zeigen, wie man mit einfachen Mitteln und WordPress Hooks die Datenbank für die Einstellungen des Plugins vornimmt, optimiert und klein hält. Ebenso ist es mir wichtig, dass die Einträge in der Datenbank gelöscht werden, wenn das Plugin deaktiviert wird.
Die Nutzer des Plugins sind sicher dankbar für diese kleinen aber feinen Codeschnippsel im Plugin.
Plugin deaktiveren, Datenbankeinträge löschen
Im ersten Punkt soll es darum gehen, die Felder, welche man in der Datenbank ablegt, auch zu entfernen, wenn das Plugin deinstalliert wird. Die Datenbank sollte schlank sein und nur die Inhalte haben, die sie auch benötigt. Daher stellt WordPress auch eine Funktion bereit, die die Desintallation einfach macht - register_deactivation_hook(). Dieser Hook wird angesprochen, wenn das Plugin deinstalliert wird. Damit könnte die Deinstallation von Einträgen in der Tabelle options wie folgt aussehen.
register_deactivation_hook(__FILE__, 'my_example_deinstall');
/**
* Delete options in database
*/
function my_example_deinstall() {
delete_option('my_example_option_1');
delete_option('my_example_option_n');
}
Plugin aktiveren, Datenbankeinträge setzen
Ähnliches gibt es auch für die Aktivierung des Plugins, der Hook register_activation_hook(). Der Codex gibt Aufschluss und die Verwendung ist analog dem obigen Beispiel mit einer Funktion für die Installation von Optionen in der Datenbank.
register_activation_hook(__FILE__, 'my_example_install');
/**
* Install options in database
*/
function my_example_install() {
add_option('my_example_option_1', '', '');
add_option('my_example_option_n', array(), '');
}
Datenbank optimieren
Hat man die Einträge aus der Datenbank entfernt, dann ist es ein schöner Zug, diese wieder zu optimieren. MySQL stellt dafür eine Funktion zur Verfügung und das Einbinden in die Funktion zum Deinstallieren der Einträge ist schnell getan.
Dazu muss die Variable der WordPress-Datenbank $wpdb global sein und die Optimierung via OPTIMIZE TABLE.
/**
* Delete options in database
*/
function my_example_deinstall() {
global $wpdb;
add_option('my_example_option_1', '', '');
add_option('my_example_option_n', array(), '');
$wpdb->query("OPTIMIZE TABLE $wpdb->options");
}
Hat man eine Funktion innerhalb des Plugins, welches des öfteren Daten in der Datenbank verändert, dann kann man das Optimieren dieser auch öfters vornehmen. Dazu binde ich es in der Regel per Zufall ein und lasse die DB dann optimieren. Beispielsweise beim Löschen von Spam-Einträgen in der DB comments ist derartiges lohnend. Ich nutze es im Plugin SpamViewer.
$n = mt_rand(1, 1000);
if ( $n == 10 )
$wpdb->query("OPTIMIZE TABLE $wpdb->options");
Update
Bei der Diskussion zu diesem Theme, siehe Kommentare, hat sich herausgestellt, dass man das Thema der Datenbank-Optimierung vorsichtig angehen sollte, denn Optimieren in Massen und zu ungünstigen Zeiten kann auch nachteilig sein. Daher bitten ich, diese Empfehlung überlegt zu nutzen. Ich für meinen Teil werde sie aus Deaktivierungsfunktionen entfernen und bei bspw. dem Löschen von großen Mengen von Daten, Beispiel Spam-Einträge, drin lassen.
Nicht benötigte Einträge löschen
Nutz das Plugin Optionen aus der Datenbank und arbeitet für jede Option einen eigenen Eintrag ab, dann ist es sinnvoll, die Einträge nicht zu speichern, die leer in den Einstellungen des Plugins sind. Am Beispiel Checkbox: wenn der User den Haken der Checkbox nicht setzt, dann wird als Übertrag 0 genommen und in der DB abgelegt, je nach Abfrage des Plugins passiert dann aufgrund dieser Einstellung etwas. Im Grunde ist es der Abfrage aber egal ob 0 oder nicht vorhandener DB-Eintrag und daher kann man diese Option auch leeren. Dies geht mir der folgenden kleinen Funktion. Dabei werden nach dem Senden der POST-Daten lediglich die Felder in der DB gespeichert, die man auch benötigt.
// for a smaller database
function my_example_get_update($option) {
if ( ($_POST[$option] == '0') || $_POST[$option] == '') {
delete_option($option);
} else {
update_option($option , $_POST[$option]);
}
}
my_example_get_update('my_example_option_1');
my_example_get_update('my_example_option_n');
Klasse HowTo - es wäre prima, wenn dies alles bald in alle WP Plugins miteinfliessen würde, dann bräuchte man selbst keine "Nacharbeit" mehr leisten.. und das CleanOptions Plugin wäre auch hinfällig bzw. würde es wohl werden (irgendwann), da WP auch die RSS Einträge/Handhabung in der options-Tabelle verbessern will und dies sicherlich irgendwann macht.
Nicht ganz das Thema, aber...
Ich habe bei deinen Plugins (c)-Feed und Search & Replace immer das Problem, dass beim Aktualisieren die neue Version in einem weiteren Unterordner entpackt wird. Hat zur Folge, dass das Plugin nach dem Update nicht mehr funktioniert. Bin ich zu blöd, oder ist das ein Bug?
@ad: habe die Struktur im SVN geändert, dass sollte seit geraumer Zeit klappen. Rückmeldung wäre schön.
Hi Frank,
vielen Dank für diesen Hinweis! Ich bereite gerade meinen Blog-Relaunch vor und arbeite deshalb an einem Plugin. Ich habe mir in der letzten Zeit viele Plugins und vor allem meine WordPress-Datenbank angeschaut und festgestellt, dass die wenigsten Plugins ihre alten (und obsoleten) Settings beim deinstallieren entfernen.
Gerade wer viel testet und Plugins ausprobiert, wird mit einer zugemüllten Options-Tabelle bestraft. Ich finde jeder Plugin-Entwickler (Ich werde es in Zukunft so machen) sollte eine Option anbieten "Optionen bei Deaktivierung entfernen", das per Default gesetzt wird.
So kann jeder User entscheiden, ob er eventuell die Settings behalten möchte - ideal wenn man ein Plugin nur testweise deinstalliert um zu debuggen oder zu testen. Einstellungen gehen in diesem Fall nicht verloren.
Danke für den Hinweis, ich hoffe, es nehmen sich einige WP-Entwickler zu Herzen!
@Tim (PHP Blogger): sehr schön, dass hat es ja schon etwas gebracht, diesen Artikel aufzusetzen. Der Hinweis, wenn man den Hook nutzt, dann werden die Einträge bei jeder Deaktivierung gelöscht! Daher ist die Option auf der options-Seite eine Möglichkeit die Daten zu halten und bspw. ein Update durch zuführen und alle Plugins zu deaktivieren. So mache ich es in den anderen Plugins, allerdings dachte ich mir bei Adminimize, dass man die Optionen besser nach jedem Deaktivieren neu setzen sollte, vermeidet Fehler beim Nutzer.
@Frank: Nehme alles zurück und behaupte das Gegenteil! Funktioniert (jetzt).
Ich biete dafür den Nutzern meines Plugins einen Button "Default-Einstellungen wieder herstellen" an. Man kennt das ja bereits von Firmware (z.B. Handys und Navis) - so hat jeder selbst Gewalt darüber, wann er die Defaults drübergebügelt bekommt.
Aber das muss natürlich immer von Fall zu Fall entschieden werden. Bei einem Plugin oder Theme mag es gut so sein, bei einem anderen ist es viell. wirklich besser, wenn man beim Aktivieren wieder die Grundeinstellungen vorgibt.
@ad: wunderbar
Die Hinweise zum Abräumen obsoleter DB-Einträge sind gut und vollkommen richtig.
Ansonsten würde ich aber den letzten beiden Punkten widersprechen wollen. Ich würde während der Lebenszeit eines Plugins auch durchaus Default-Einträge in der DB stehen lassen. Falls andere Plugins diese Werte evtl. ebenfalls nutzen baut man sonst nur unnötige Abhängigkeiten auf. Mal abgesehen davon das wir hier wohl eher nicht von Tabellen mit Datensätzen > 1.000.000 reden, oder?
Auch das ständige Optimieren der Tabellen kann ich nicht gutheissen. Je nachdem welche Primary Keys bei den nächsten Inserts verwendet werden kann es nämlich sein das dann die DB-Engine erst wieder aufwändig die Pages umsortieren muss um den neuen Primary Key an der richtigen Stelle einsortieren zu können. Wenn an dieser Stelle noch leerer Platz vom vorhergehenden Löschen vorhanden ist kann er direkt genutzt werden. Und das geht deutlich performanter als wenn erst Platz geschaffen werden muss.
Die Kombination beider Methoden (Default-Werte aus DB löschen und ständiges Optimieren) kann dann schnell dazu führen das man das Gegenteil von dem erreicht was man will: Mehr Last für den DB-Server anstelle weniger.
@Uwe: Das Optimieren soll ja daher per Zufall passieren, immer wäre zu viel und dann treffen deine Punkte zu. Aktuell binde ich sie nur ein, damit nach dem Deinstallieren des Plugins, was ja an sich nicht häufig vorkommt, die Tabelle optimiert wird.
Datenbank-Einträge eines Plugins werden an sich nie von anderen Plugins benötigt. Ich empfinde es auch nur als besser, die Einträge zu löschen, die man nicht benötigt (0, ''), nicht die default-Einträge. Die Tabellen bewegen sich in der Regel bei 100-200 Einträgen, mir sind aber auch schon Tabellen untergekommen, in denen 2500 Einträge waren, weil man die Einträge nach dem Deaktivieren eines Plugins nicht entfernt hat. im laufe eines Bloglebens wird so einiges am Liveblog getestet.
Wenn jedes Plugin die Tabelle zufällig optimiert, dann wird u.U. die Tabelle an einem Tag zehn mal von verschiedenen Plugins optimiert. Gelinde gesagt: Blödsinn. Oder?
Besser wäre es wenn die Optimierung von einem eigenen Pflege-Plugin durchgeführt wird. Dieses könnte dann auch bei jeder Deinstallation (besser gesagt, bei jeder Deaktivierung) eines Plugins gestartet werden.
Die Tabelle nach einer Deinstallation/Deaktivierung zu optimieren finde ich auch etwas übertrieben. Es werden vielleicht 10,20 oder 30 Einträge gelöscht. Kein wirklicher Grund die Tabelle zu optimieren.
Uwe hat da schon recht: Wenn jedes Plugin die Tabelle/Datenbank pflegt, kann es schnell mal zuviel des Guten werden.
@Ralf: das heißt aber auch, dass der User 10 Plugins pro Tag deaktivieren muss. Blödsinn. Oder?
@Frank: gerade bei Spam, lösche ich des öfteren 100te oder 1000te Einträge.
Die Diskussion zeigt ja auch, dass es ein Thema ist und so mehr Input bringt. Ich werde es mir genauer ansehen.
Bei meinem Kommentar sind wohl zwei Punkte durcheinander gekommen.
Du schreibst, dass es sinnvoll wäre wenn ein Plugin die Datenbank/Tabelle optimiert wenn es in den Tabellen häufiger Änderungen vornimmt (z.B. Spam löscht). Eine Optimierung lohnt sich meistens aber nur dann, wenn massiv Daten geändert/gelöscht wurden.
Wirklich massive Änderungen stehen eigentlich nur dann an, wenn Spam gelöscht wird. Ansonsten fallen mir nicht viele Aktionen ein wo massiv was an den Daten geändert wird.
Deswegen denke ich das es bei den allermeisten Plugins arg übertrieben wäre wenn diese auch noch die Tabellen optimieren würden. Zumal dann eben das eintreten könnte, was ich oben beschrieben habe. Viele Plugins optimieren die Tabelle weil sie Daten ändern/löschen und jedes Plugin optimiert erstmal die Tabelle(n).
Beim Deinstallieren kommt es natürlich darauf an wie viele Daten ein Plugin gespeichert hat und wo. Wenn z.B. ein Statistik-Plugin deinstalliert wird, werden wohl recht viele Daten gelöscht. Allerdings stehen die i.d.R. in einer eigenen Tabelle. Da diese gelöscht wurde, kann man sie schlecht optimieren. Und die paar Einträge die in der Tabelle wp_options gemacht wurden, da lohnt sich seltenst eine Optimierung.
Ich halte es einfach für die bessere Strategie die Pflege der DB/Tabellen in einem Rutsch durchzuführen. Das am besten auch dann, wenn nicht gerade Besucherspitzen zu verzeichnen sind. Also per Crown-Job irgendwann nachts.
Denn überleg mal was passieren würde wenn zur Mittagszeit gerade viele Besucher vorbei kommen die einen Kommentar hinterlassen und du gleichzeitig in der Mittagspause mal eben Spam löscht was dazu führt das die Tabelle optimiert wird. Im schlimmsten Fall kommen einzelne Kommentare nicht durch weil eben die Tabelle während er Optimierung gesperrt ist. Das eine Optimierung gerade bei einigen tausend Kommentaren nicht mal eben so durchgeführt ist, dürfte auch klar sein.
@Ralf: definitiv, die Pflege einem Bereich zu übergeben wäre sinnvoller. Es sollte ja auch nur ein Anreit und Möglichkeit sein. Eventuell schreibe ich das nochmal um und stelle es so dar, wie wir es hier in den Kommentaren sehen. Am besten wäre wohl eine Funktion dafür zu haben und die über alles zu steuern.
Ich weiß, der Beitrag soll nur verdeutlichen wie man es machen kann. Wenn ich es mir aber genau überlege, dann wäre es eigentlich Aufgabe von WordPress die Plugins und deren Installationsreste zu verwalten. Wenn schon ein Blogsystem die Möglichkeit bietet Plugins zu verwenden, dann ist es quasi ein Armutszeugnis wenn es keine Funktionen gibt um anschließend wieder aufzuräumen.
Es wäre ganz gut gewesen wenn es bei WP eine Funktion geben würde mit deren Hilfe man Tabellen anlegen kann. Diese Funktion würde dann gleichzeitig protokollieren welches Plugin welche Tabellen angelegt hat und in welchen Tabellen das Plugin Daten geschrieben hat. Dann wäre es auch kein Problem einen Menüpunkt "Plugins deinstallieren" anzubieten der entsprechende Datenreste weg putzen kann.
So ist das Zumüllen der Datenbank vorprogrammiert, ein Punkt der nicht gerade für WordPress spricht. Merkwürdig das sich die Entwickler bis jetzt darüber noch keine gedanken gemacht haben und alles auf die Pluginentwickler abwälzen.
@Ralf: stimme ich voll zu, schiebe es aber auf das viel zu schnelle Wachstum von WP; WP ist zu schnell zu groß und populär geworden, es war keine Zeit mit den Anforderungen zu wachsen und mittlerweile sind die Anforderungen sehr hoch und die Prioritäten kommen aus anderen Richtungen, denn nur von OSS kann man nicht leben. Schau ich mir andere Applikationen mit ähnlichen offenen Schnittstellen an, auch Businesssystem für viel Geld, dann sehe ich kaum bessere lösungen.
Wer bis WP 2.7 nicht warten will ...
Das Plugin installiert nach Wahl Themes und Plugins und löscht auch beides. Bei den Plugins Löschung mit Nachfrage und genauer Ordnerauflistung. Es kann wohl auch automatisch die Wahl zwischen Plugin und Theme-Upload treffen, aber soweit wollte ich mich darauf nicht verlassen.