Verunreinigen Sie nicht die WordPress-Optionstabelle
Ich bin ein Fan von kurzen Release-Zyklen. Je nach Projekt variiert die Länge des Zyklus, aber für viele Arten von Projekten, an denen ich arbeite, strebe ich zweiwöchige Veröffentlichungszyklen an.
Außerdem gibt es Zeiten, in denen ich an einem Projekt für jemanden arbeite, bei dem Umgebungsvariablen erforderlich sind, damit der Code weiß, ob er in der Entwicklung, Bereitstellung oder Produktion ausgeführt wird.
Und dies kann je nach den Anforderungen des Projekts auf unterschiedliche Weise erreicht werden. Manchmal funktioniert eine Konfigurationsdatei, manchmal können Abfragezeichenfolgenvariablen funktionieren, und manchmal denke ich, dass es sinnvoll ist, eine Einstellung in der Datenbank zu speichern.
Aber was WordPress betrifft, denke ich, dass wir bessere Designentscheidungen abkürzen und Informationen in die Datenbank werfen, insbesondere in die Optionstabelle, wenn Alternativen besser geeignet sind.
Die WordPress-Optionstabelle
Ich möchte das klarstellen: Ich glaube nicht, dass die Optionstabelle als Abladeplatz für Einstellungen dienen sollte, wenn Sie sonst nirgendwo Informationen ablegen können. Und das ist der Kern dieses ganzen Beitrags.
Stattdessen können Sie Folgendes verwenden:
- eine Konfigurationsdatei,
- Sitzungsdaten (falls zutreffend),
- eine benutzerdefinierte Datenbanktabelle,
- oder etwas anderes.
Warum sehen wir das so häufig? Es ist nicht so, dass es keine Zeiten gibt, in denen es sinnvoll ist, es zu verwenden. Ich denke nur, wir missbrauchen es. Aber es gibt Gründe dafür.
Der WordPress Codex definiert Optionen wie diese:
Optionen sind Datenelemente, die WordPress verwendet, um verschiedene Einstellungen und Konfigurationseinstellungen zu speichern.
Mit einer Definition wie dieser ist es leicht zu verstehen, warum so viele es als Aufbewahrungsort für alles verwenden, was nirgendwo anders hinpasst.
Stattdessen halte ich es für wichtig, die Frage zu stellen:
Für welche Art von Speicherung sind [diese Daten] am relevantesten?
Das heißt, wenn es sich auf Posts bezieht, warum speichern Sie es dann nicht in der Post-Metatabelle? Gleiches gilt für Begriffsmetadaten oder Kommentare oder irgendetwas anderes.
Der Punkt ist folgender:
Finden Sie den logischsten Ort zum Speichern der Daten und legen Sie sie dort ab.
Mit anderen Worten, wirf keine Daten in die WordPress-Optionstabelle, weil sie nirgendwo anders hinpassen. Das verschmutzt es. Finden – oder schaffen – Sie stattdessen den logischsten Ort dafür. Das ist wahrscheinlich ein Beweis für einen Code-Smell und wäre ein guter Grund, die Architektur Ihres Codes und die Darstellung von Informationen neu zu bewerten.
Aber wie könnte das aussehen? Das heißt, wie würden wir ein bestimmtes Stück Code nehmen und ändern, wie es in der Datenbank dargestellt wird.
Leider ist es schwierig, eine vorschreibende Lösung für diese Frage bereitzustellen, wenn so viele Variationen der Implementierung eines Problems existieren. Vielleicht ist eine einfache Richtlinie angebracht:
Wenn sich die Daten auf die bereits vorhandenen Datentypen (oder Tabellen) beziehen, verwenden Sie diese; Ziehen Sie andernfalls eine Konfigurationsdatei oder eine benutzerdefinierte Datenbanktabelle in Betracht, die Ihrer Arbeit entspricht.
Ich bin mir sicher, dass es andere Leitfaktoren gibt, aber dies ist ein besserer Ausgangspunkt, als einfach die WordPress-Optionstabelle zu verschmutzen.