Benutzerdefinierte Felder statt in wp_postmeta in echten, typisierten Tabellen zu speichern, bringt Sortierung, Indizierung und korrekte Typen, wie an anderer Stelle in diesem Blog beschrieben. Es bringt aber auch eine Risikokategorie mit, die wp_postmeta nie hatte: Schemaänderungen. Eine Spalte umzubenennen oder ihren Typ zu ändern ist ein normaler Datenbankvorgang, aber nicht automatisch ein sicherer – und ein Plugin, das Tabellen in Ihrem Auftrag verwaltet, muss das ernst nehmen.
Dieser Beitrag beschreibt, was in Mass Custom Fields mechanisch tatsächlich passiert, wenn Sie ein Feld umbenennen, seinen Typ ändern oder es entfernen – und was Table health tut, wenn Ihre Feldgruppendefinitionen und Ihre tatsächlichen Tabellen auseinanderlaufen.
Die Regeln hinter jedem Speichern
Jedes Feld ist eine Spalte, daher verändert das Bearbeiten einer gespeicherten Feldgruppe eine echte Tabelle. Vier Regeln gelten bei jedem Speichern:
- Erst die Tabelle, dann die Definition. Zuerst wird die Tabelle geändert. Nur wenn das geklappt hat, wird die Feldgruppendefinition gespeichert, sodass ein fehlgeschlagenes Speichern beide nicht auseinanderlaufen lassen kann.
- Ganz oder gar nicht. Schlägt ein Schritt fehl, etwa weil ein neuer Unique-Index auf doppelte Werte trifft, werden die bereits ausgeführten Schritte rückgängig gemacht, und die Meldung endet mit „Nothing was changed.“
- Entfernen löscht nie Daten. Die Spalte eines entfernten Felds bleibt in der Tabelle erhalten.
- Riskante Umwandlungen behalten ein Backup. Vor einer Umwandlung, die Daten verlieren könnte, werden die alten Werte in eine Backup-Spalte kopiert.
Ein Feld umzubenennen verliert keine Daten
Wenn Sie den Key eines Felds ändern, ist der zugrunde liegende Vorgang eine Spaltenumbenennung und kein Löschen und Neuanlegen. Die Daten in dieser Spalte bleiben genau dort, wo sie sind; nur der Name der Spalte ändert sich, und die Indizes des Felds werden mit umbenannt. Der Editor warnt Sie vor dem Speichern, dass die Umbenennung RENAME COLUMN ausführt. Der naive Weg, eine Spalte umzubenennen – eine neue anlegen, Werte hinüberkopieren, die alte löschen –, ist bei großen Tabellen langsamer und hat mehr Fehlerquellen.
ALTER TABLE wp_wpmcf_fg_product
RENAME COLUMN release_date TO launch_date;Aktualisieren Sie nach einer Umbenennung die Templates, Shortcodes und den Code, die noch den alten Key verwenden.
Ein Feldtyp-Wechsel bewahrt den alten Wert
Den Typ eines Felds zu ändern ist riskanter als eine Umbenennung, weil nicht jeder Wert im alten Typ sauber in den neuen umgewandelt wird. Eine TEXT-Spalte auf ein kürzeres VARCHAR zu kürzen kann echte Daten abschneiden; freier Text, der in eine Zahl umgewandelt wird, macht nicht numerische Werte zu NULL oder 0.
Bei einer riskanten Änderung zeigt der Editor den Dialog „This type change can lose data“ mit drei Optionen:
- Cancel, und nichts ändert sich.
- Convert with a backup. Die alten Werte werden zuerst in eine Spalte namens
{key}__bakgesichert. Prüfen Sie nach dem Speichern die umgewandelten Werte und löschen Sie das Backup unter Table health, sobald Sie zufrieden sind. - Create a new field instead. Es wird ein zweites Feld mit dem neuen Typ hinzugefügt und die alte Spalte bleibt unangetastet – passend, wenn Sie Werte nach eigenen Regeln migrieren möchten.
Eine kompatible Änderung, etwa von Text zu Text area, passt einfach die Spalte an und behält die Werte.
Ein Feld zu entfernen löscht Ihre Daten nicht
Wenn Sie ein Feld im Editor entfernen, wird die Felddefinition entfernt – das, was es bearbeitbar und sichtbar macht –, aber die Spalte und ihre Werte bleiben als übrig gebliebene Spalte in der Tabelle. Das Löschen von Daten ist eine separate, ausdrückliche Aktion. Auch das Deaktivieren des Plugins löscht nichts, und beim Deinstallieren werden Daten nur entfernt, wenn Sie die Löschoption in den Einstellungen aktivieren.
Wenn Sie ein neues Feld mit demselben Namen wie eine übrig gebliebene Spalte anlegen, fragt der Editor, ob das neue Feld die gespeicherten Werte verwenden oder leer beginnen soll, und verschiebt im zweiten Fall die alten Werte in eine Backup-Spalte.
Was Drift bedeutet und warum sie entsteht
Drift ist jede Abweichung zwischen dem, was die Definition einer Feldgruppe als Tabellenstruktur vorsieht, und dem, wie die Tabelle tatsächlich aussieht. Sie kann aus ganz gewöhnlichen Gründen entstehen: Ein Entwickler hat SQL ausgeführt, ein Migrationstool hat eine Spalte gelöscht oder ein Backup wurde nur teilweise wiederhergestellt.
Table health soll das sichtbar machen, statt es später als verwirrenden Fehler entdecken zu lassen. Für jede gespeicherte Gruppe zeigt es ein Zustandsabzeichen und Größenstatistiken sowie ein Panel „Table differences“ mit bis zu drei Listen:
Liste | Bedeutung | Aktionen |
|---|---|---|
Missing columns | In der Feldgruppe definiert, aber in der Tabelle nicht vorhanden | Add to DB |
Leftover columns | In der Tabelle, aber nicht in der Definition, einschließlich Backup-Spalten | Import as fields, Remove from DB |
Changed outside the plugin | Der SQL-Typ in der Datenbank weicht von der Definition ab | Sync to DB |
Tabellen ganz ohne Feldgruppe erscheinen als nicht registrierte Tabellen oben in der Liste Field Groups. Sie können sie als Gruppe registrieren oder löschen.
Details zu jedem Panel finden Sie unter Table health.
Große Tabellen werden im Hintergrund geändert
Manche Schemaoperationen – etwa einen Index zu einer Tabelle mit sehr vielen Zeilen hinzuzufügen – laufen nicht sofort ab. Hat eine Tabelle etwa 100.000 Zeilen oder mehr, wird die Änderung in eine Warteschlange gestellt und im Hintergrund über Action Scheduler ausgeführt, denselben Job-Runner, den auch WooCommerce verwendet. Der Editor zeigt ein Abzeichen „Updating“, die Website nutzt bis zum Abschluss der Änderung weiter die bisherige Definition, und zwischenzeitlich gespeicherte Werte bleiben erhalten. Eine Änderung in der Warteschlange lässt sich abbrechen; eine bereits laufende nicht.
Fazit
Ein Plugin, das echte Tabellen in Ihrem Auftrag verwaltet, muss Schemaänderungen mit derselben Sorgfalt behandeln, die ein gewissenhafter Entwickler von Hand aufbringen würde: Umbenennungen, die keine Daten verschieben, Typänderungen mit Weg zurück, Entfernungen, die die Spalte erst auf Ihre Anweisung hin anrühren, und ein Panel, das Ihnen sagt, wenn Realität und Definition auseinandergehen. Die vollständigen Regeln stehen unter Feldgruppen sicher ändern.
