Advanced Custom Fields ist ein fantastisches Plugin, das von Millionen genutzt wird und WordPress in ein vollständiges CMS verwandelt. Es ermöglicht Ihnen, unbegrenzte benutzerdefinierte Feldgruppen und -typen zu erstellen und diese zu jedem beliebigen benutzerdefinierten Beitragstyp hinzuzufügen.
Allerdings wissen nur wenige über die Skalierbarkeitsgrenzen von Advanced Custom Fields Bescheid.
Wir werden häufig gefragt, ob GeoDirectory Advanced Custom Fields zur Verwaltung benutzerdefinierter Felder für Einträge verwendet.
Wenn wir antworten, dass GeoDirectory über ein eigenes, integriertes benutzerdefiniertes Feldsystem verfügt, fragen sie sich, warum wir uns entschieden haben, „das Rad neu zu erfinden".
Für uns ist die Antwort glasklar: Die Skalierbarkeit von Advanced Custom Fields ist beim Aufbau von Verzeichnissen sehr begrenzt.
Wir dachten, dass sich die Nutzer als Anwender möglicherweise nicht bewusst sind, was im Hintergrund passiert und welche Skalierbarkeitsprobleme ein Web-Verzeichnis mit sich bringen kann.
Vor nicht allzu langer Zeit sind wir jedoch auf eine Umfrage in einer beliebten WordPress-Gruppe auf Facebook, where the options to vote for the "Best Directory" were: GeoDirectory, a few other Directory Themes available on popular marketplaces and there was also the option ACF + FacetWP.
When we saw the results, we were perplexed, to say the least, ACF + FacetWP had a lot more votes than we would have thought.
People who voted were not supposed to be just simple users, but website developers and WordPress experts.
For this reason, we decided it was time to explain why it is NOT a good idea to use Advanced Custom Fields for a directory.
And why Web Developers shouldn’t offer that solution to anyone unless they don’t care about providing fast, scalable solutions to their customers, that can grow sustainably.
WordPress Custom Fields Scalability Limits
WordPress by default uses the wp_postmeta database table to store custom field data, and it creates 1 row for each custom field used in a post.
Other than that WordPress adds a lot of extra data in this table for each post, each of which will use 1 row of the table.
If you spent some time optimizing SQL queries, you’ll know that’s not an ideal scenario for things like directories and filtering.
Tatsächlich ist die standardmäßige Datenbankstruktur ein potenziell enormer Flaschenhals für Websites mit vielen Beiträgen und benutzerdefinierten Feldern.
Sie gilt als einer der Schwachpunkte von WordPress.
Der Grund dafür ist, dass Sie zum Filtern von Beiträgen nach benutzerdefinierten Feldern die Tabelle wp_post mit der Tabelle wp_postmeta in Ihrer Abfrage verknüpfen müssen.
Je größer die Tabellen werden, desto langsamer werden die Abfragen.
Am schlimmsten ist es, wenn Sie nach zwei Meta-Werten filtern möchten – dann müssen Sie die Tabelle post_meta in einer einzigen Abfrage zweimal verknüpfen.
Dies kann den Systemspeicher aufbrauchen und alles verlangsamen – außer bei einem kleinen Verzeichnis.
Skalierbarkeitsgrenzen von Advanced Custom Fields
Das Advanced Custom Fields Plugin ist perfekt für jede Website mit einer geringen oder moderaten Anzahl von Beiträgen, Seiten und benutzerdefinierten Feldern im Allgemeinen.
Bei Verzeichnissen ist es jedoch – bis auf wenige Ausnahmen – genau umgekehrt.
Sie haben eine sehr hohe Anzahl von Beiträgen und potenziell auch eine sehr hohe Anzahl benutzerdefinierter Felder.
Das primäre Skalierbarkeitsproblem von Advanced Custom Fields besteht darin, dass für jedes benutzerdefinierte Feld, das einem Eintrag hinzugefügt wird, 2 Zeilen in der wp_postmeta-Tabelle Ihrer Datenbank erstellt werden.
Außerdem werden mehrere Postmeta-Zeilen hinzugefügt, die zu den eigenen Einstellungen gehören.
Das bedeutet, dass im Vergleich zur Verwendung des Standard-WordPress-Systems für benutzerdefinierte Felder mehr als doppelt so viele Zeilen in der wp_postmeta-Tabelle Ihrer Datenbank hinzugefügt werden.
Wir haben einen kurzen Test durchgeführt, der dabei helfen soll, diesen Sachverhalt besser zu erklären.
Wir haben eine neue WordPress-Website erstellt, den „Hello World"-Beitrag und die Beispielseite gelöscht und Advanced Custom Fields installiert.
Wir haben 1 Gruppe und 5 benutzerdefinierte Felder erstellt und 3 Beiträge veröffentlicht, die jeweils die 5 benutzerdefinierten Felder verwenden.
Danach zählte unsere wp_postmeta-Tabelle bereits 83 Zeilen.
Das ist absurd.
Stellen Sie sich die Anzahl der Zeilen für ein Verzeichnis mit 300.000 Einträgen und fünf benutzerdefinierten Feldern vor.
Mit ACF würde Ihre wp_postmeta-Tabelle mindestens 3.000.000 Zeilen zählen
Wie skaliert GeoDirectory?
Das ist ganz einfach: Wir erstellen eine benutzerdefinierte Tabelle für jeden unserer benutzerdefinierten Beitragstypen.
Beispiel: wp_gd_gd_place_detail
In dieser Tabelle speichern wir alle benutzerdefinierten Felder und deren Daten in einer Zeile pro Beitrag.
Wir haben auch eine eigene PHP-API entwickelt, um unsere benutzerdefinierten Tabellen abzufragen – genau wie WordPress eine eigene PHP-API zum Abfragen der Standard-WordPress-Datenbanktabellen hat.
Das bedeutet, dass GD in den meisten Fällen nur die Beitragstabelle mit unserer Tabelle verknüpfen muss.
Anschließend können wir diese Ergebnisse nach JEDEM benutzerdefinierten Feld filtern.
Wir könnten nach 20 benutzerdefinierten Feldern filtern, während ACF – selbst mit facetWP (was die Dinge zwar beschleunigt, aber dennoch die grundlegende Einschränkung hat) – mehrere Tabellen immer wieder verknüpfen müsste, um dieselbe Aufgabe in einer einzigen Abfrage zu erledigen, und dabei ein Vielfaches des Serverarbeitsspeichers für dieselbe Abfrage benötigt.
Fazit
Wenn wir also GeoDirectory mit WordPress oder WP + Advanced Custom Fields vergleichen, sehen wir Folgendes:
WordPress
1) Für jedes benutzerdefinierte Feld, nach dem gefiltert werden soll, ist ein zusätzlicher Tabellen-JOIN erforderlich.
2) wp_postmeta wird schnell groß und verlangsamt die Abfragen
WP + ACF
1) Für jedes benutzerdefinierte Feld, nach dem gefiltert werden soll, ist ein zusätzlicher Tabellen-JOIN erforderlich.
2) wp_postmeta wird doppelt so groß im Vergleich zur alleinigen Verwendung von WordPress
GeoDirectory
1) Kein JOIN erforderlich
2) GD fügt keine Daten zur wp_postmeta hinzu und erzeugt daher keinen unnötigen Overhead.
3) Die Datenbank, in der Eintragsdata gespeichert wird, zählt 1 Zeile pro Beitrag
WordPress ist für diese Einschränkung bei der Datenspeicherung bekannt. In den meisten Fällen funktioniert dieses System gut, aber bei großen Verzeichnissen ist es einfach nicht die richtige Lösung.
Genau deshalb können Sie mit GeoDirectory ein Verzeichnis mit Millionen von Einträgen erstellen, während Sie mit WP + Advanced Custom Fields froh sein können, wenn Sie ein Verzeichnis mit einigen Hundert Einträgen erstellen können, bevor gravierende Performance-Probleme auftreten.
Dies sind die Skalierbarkeitsgrenzen von Advanced Custom Fields, die uns dazu bewogen haben, es nicht für GeoDirectory zu verwenden – und deshalb sollten auch Sie es nicht einsetzen.
Wenn Sie Fragen haben, stellen Sie diese gerne im Kommentarbereich unten.