Probleme durch aufgeblähte wp-options Tabelle
Wenn wir Websites in der Wartung betreuen, die wir nicht selbst entwickelt haben, kommt so manche Blüte zum Vorschein.
Das Plugin DSGVO All in one for WP verspricht eine umfassende Lösung für die DSGVO-Absicherung einer Website – bei näherer Betrachtung sehen wir aber weniger ein umfassendes Konzept, sondern eine Sammlung unterstützter Plugins, die irgendwie DSGVO-konform gemacht werden – wer Alternativen nutzen möchte, hat schnell ein Problem. Oder auch wer mehr als 5 eigene Tracking-Scripte einbauen möchte – manche Grenzen wirken beliebig.
Aber wer mit dem Featureset zufrieden ist, für den sollte das Plugin ja eine saubere technische Umsetzung der DSGVO-Anforderungen ermöglichen.
Dazu gehört auch, dass die Reaktionen auf das Cookie-Banner gelogged werden sollten, damit beispielsweise Zustimmungen zum Tracking auch nachträglich noch nachvollziehbar sind – Usercentrics hält hierzu genauso Logs vor.
Es geht jedoch um die Art und Weise, wie DSGVO All in one for WP die Logs speichert.
wp_options ist nicht für Logs
Daten richtig speichern
Logs haben es an sich, dass sie gerne ein Eigenleben entwickeln – sie fangen sehr klein an – und können monströse Größen annehmen.
Bei unserem Kunden wurde die Größe der wp_options-Tabelle innerhalb von etwa einem halben Jahr um über 450% aufgebläht – von ca. 4,18 MB zu 23,80 MB.
Aufgefallen war uns das, weil ein Import der wp_options-Tabelle über PHPmyAdmin, Plesk und verschiedene SQL-Dump-Scripts fehlschlug – Grund war eine einzelne Insert-Query für ein Feld, das knapp 20 Megabyte Textdaten enthielt – der MySQL-Server brach einfach ab.
Doch nicht nur die Wartung wird so erschwert – auch die Website-Performance nimmt spürbar ab – mit der Zeit immer mehr. WordPress-Options werden standardmäßig bei jedem Seitenaufruf geladen. Bei jedem Seitenaufruf wird damit die Abfrage gestartet und die Ladedauer der Seite unnötig erhöht.
Update – Nach Anmerkung des Pluginautors muss richtiggestellt werden:
Standardmäßig wird der Log-Eintrag nicht geladen und beeinträchtigt die Performance daher nur dann direkt, wenn ein neuer Eintrag hinzugefügt oder die vorhandenen Einträge ausgelesen werden, was bei einem einfachen Seitenaufruf nicht geschieht.
Best Practice bleibt, die Logs in einer eigenen Tabelle zu speichern.
Refactoring & Pair-Programming
Funktioniert doch – reicht nicht
Es geht in diesem Artikel nicht darum, das Plugin eines Entwicklerkollegen zu diskreditieren – die Basisversion ist kostenlos und jeder hat die Möglichkeit Feedback zu äußern, genauso ist dem Plugin Review Team von WordPress das Problem nicht aufgefallen – das Problem tritt erst auf, wenn eine Website länger im Einsatz ist oder viele Besucher hat.
Vielmehr ist das Beispiel exemplarisch dafür, wie architektonische Fehler in der Entwicklung entstehen können und niemandem fallen sie auf.
Ein regelmäßiges Refactoring, Code Reviews von Dritten oder Pair Programming können solche Problemstellen gut adressieren – bis hin zu automatisiertem Testing. All das ist aufwändig, kostet Zeit und Geld.
Auch unsere Software ist davor nicht gefeit und wir alle müssen uns eingestehen, dass es keine perfekte Software geben kann. Dennoch sind solche Fehler natürlich vermeidbar und über kurz oder lang kann eine ausufernde Log-Datei die Stabilität einer Website beeinträchtigen.
Bei von uns in der Vergangenheit überprüften DSGVO-Plugins zieht sich jedoch ein roter Faden durch: die rechtliche Exzellenz sticht häufig die technische Exzellenz.
Umso wichtiger ist daher eine technische Prüfung der genutzten oder gewünschten Pluginlösungen für den konkreten Zweck.
Unsere Empfehlung wäre ohnehin grundsätzlich: Kein Cookie Konsens erforderlich, also der Verzicht auf Cookie Banner.