Was beim Deinstallieren eines Plugins verloren geht
Deaktivieren ändert ein einziges Feld. Deinstallieren löscht die Plugin-Konfiguration, eigene Entitäten — und Custom Fields, in denen Händlerdaten stehen. Der destruktive Weg ist der Standard.
„Das Plugin brauchen wir nicht mehr." Danach folgt in vielen Projekten ein Klick, und ein paar Wochen später fehlen Daten, von denen niemand wusste, dass sie am Plugin hingen. Wir haben nachgemessen, was die beiden Wege tatsächlich tun.
Deaktivieren: ein Feld
Ein Plugin in einer laufenden Installation deaktiviert, den Bestand vorher und nachher verglichen:
| vorher | nachher | |
|---|---|---|
| Tabellen in der Datenbank | 275 | 275 |
| aktive Plugins | 9 | 8 |
Einträge in system_config | 167 | 167 |
| Produkte | 18 | 18 |
Nichts wurde entfernt. Die Tabellen des Plugins stehen weiter, seine
Konfiguration steht weiter, seine Daten stehen weiter. Geändert hat sich das Feld
active.
Ein deaktiviertes Plugin ist also ein Plugin im Ruhezustand — es greift nicht mehr ein, aber alles ist da. Wieder einschalten stellt den Zustand her.
Deinstallieren: fünf Löschschritte
Der Ablauf im Kern ist eindeutig, und die Reihenfolge ist aufschlussreich:
public function uninstallPlugin(
PluginEntity $plugin,
Context $shopwareContext,
bool $keepUserData = false // <- Voreinstellung
): UninstallContext {
Danach passiert, sofern keepUserData nicht gesetzt ist:
| Schritt | was entfernt wird |
|---|---|
| 1 | die Assets des Bundles — unabhängig von keepUserData |
| 2 | die Migrationen des Plugins |
| 3 | uninstall() des Plugins — im Kern kommentiert als „will remove the tables etc of the plugin" |
| 4 | die gesamte Plugin-Konfiguration aus system_config |
| 5 | Custom Entities und Custom Fields des Plugins |
Dazu, falls das Plugin es deklariert, ein composer remove.
Der Schritt, der wirklich wehtut
Schritt 5.
Custom Entities sind Plugindaten — dass sie mitgehen, ist konsequent.
Custom Fields sind es nicht. Ein Plugin legt ein Feld an, ein Mitarbeiter pflegt über Monate Werte hinein, und beim Deinstallieren verschwindet beides: die Felddefinition und die Inhalte. Das sind Daten, die niemand als „Plugindaten" wahrnimmt — sie stehen an Produkten, an Kunden, an Bestellungen.
Wer wissen will, wie groß das Risiko im eigenen Shop ist, zählt vor dem Deinstallieren die Custom Fields des Plugins und die Zahl der Datensätze, die einen Wert darin haben. Das ist eine SQL-Abfrage und die einzige, die vor dieser Entscheidung wirklich zählt.
Die Voreinstellung ist die gefährliche
bool $keepUserData = false — der Standard ist der destruktive Weg. Auf der
Kommandozeile:
--keep-user-data Keep user data of the plugin
Eine Option, die man aktiv angeben muss. Wer sie nicht kennt, deinstalliert vollständig.
Bemerkenswert ist der Kommentar an Schritt 2. Die Migrationen werden vor dem eigentlichen Deinstallieren entfernt, „so we can recover in case of errors by rerunning the migrations". Das ist eine Fehlerbehandlung für einen abgebrochenen Vorgang — und keine Rückgängig-Funktion für einen erfolgreich abgeschlossenen.
Die Entscheidung
| Situation | Weg |
|---|---|
| Plugin macht Probleme, Ursache unklar | Deaktivieren. Reversibel, sofort, ohne Datenverlust |
| Plugin wird ersetzt, Daten sollen übernommen werden | Deaktivieren, Daten migrieren, danach deinstallieren |
| Plugin war ein Versuch, nie produktiv genutzt | Deinstallieren — vorher trotzdem nachsehen, ob Custom Fields existieren |
| Shop wird aufgeräumt, Plugin seit Jahren aus | Deinstallieren mit --keep-user-data, wenn Unsicherheit besteht. Der Preis sind ein paar verwaiste Tabellen |
| Lizenz läuft aus, Plugin muss weg | Sicherung, dann deinstallieren. In dieser Reihenfolge |
Die praktische Regel ist einfach: Deaktivieren ist eine Entscheidung, Deinstallieren ist ein Vorgang. Die Entscheidung darf man revidieren, den Vorgang nicht.
Grenzen dieser Messung
Das Deaktivieren wurde an einer laufenden Installation durchgeführt und der Bestand vorher und nachher gezählt. Der Deinstallationsweg wurde im Kern gelesen, nicht an einem Plugin mit eigenen Tabellen und Custom Fields durchgespielt — dafür hätte ein Testsystem mit gepflegten Daten aufgebaut werden müssen.
Was ein einzelnes Plugin in seiner eigenen uninstall()-Methode tut, bestimmt
das Plugin. Der Kern ruft sie auf; was darin steht, kann von Hersteller zu
Hersteller abweichen. Diese Messung beschreibt den Rahmen, nicht jeden Inhalt.
Häufige Fragen
- Was ist der Unterschied zwischen deaktivieren und deinstallieren?
- Deaktivieren setzt ein Flag und lässt alle Daten stehen. Deinstallieren entfernt die Tabellen, die Konfiguration, die Custom Entities und die Custom Fields des Plugins — sofern man nicht ausdrücklich widerspricht.
- Was macht --keep-user-data?
- Es verhindert drei Löschschritte: das Entfernen der Migrationen, das Verwerfen der Plugin-Konfiguration und das Löschen von Custom Entities und Custom Fields. Die Option ist nicht voreingestellt, sie muss angegeben werden.
- Verliere ich Produktdaten?
- Die Kerndaten nicht. Aber Custom Fields, die das Plugin angelegt hat, werden mitsamt Inhalten entfernt — und in denen stehen oft gepflegte Händlerdaten, etwa Zusatzattribute an Produkten.
- Kann ich das rückgängig machen?
- Nur aus einer Sicherung. Der Kern entfernt die Migrationen absichtlich vor dem eigentlichen Deinstallieren, damit sich ein abgebrochener Vorgang durch erneutes Ausführen der Migrationen reparieren lässt — das ist eine Fehlerbehandlung, kein Rückgängigmachen.