WordPress Multisite: ACF Pro als Frontend für ein netzwerkweites Lernsystem

Ein eCoach-Projekt auf Basis von WordPress Multisite warf eine zunächst unscheinbare Frage auf: Sollen Lernerdaten site-spezifisch oder netzwerkweit gespeichert werden? Die Antwort bestimmte nicht nur die Architektur, sondern auch die Grenzen von ACF Pro Custom Tables – und führte zu einer eleganten Lösung.

Datenhoheit entscheidet über die Architektur

WordPress Multisite ist mehr als eine Sammlung einzelner WordPress-Installationen. Es ist ein Netzwerk, in dem Daten entweder lokalen Websites oder der gesamten Plattform zugeordnet sind.

• Lokale Daten: Individuelle Seiten, Beiträge, Theme-Einstellungen oder site-spezifische Inhalte bleiben getrennt. Jede Website verwaltet ihre eigenen Tabellen wie wp_1_posts oder wp_2_posts.
• Netzwerkweite Daten: Globale Nutzer, gemeinsame Berichte oder cross-site-Beziehungen benötigen eine zentrale Speicherung. Hier ist eine Tabelle wie wp_learner sinnvoll – unabhängig von der aktuellen Site.

Im eCoach-Projekt gehörte die Lernerverwaltung dem gesamten Netzwerk. Ein Duplikat pro Site hätte nicht nur Speicherplatz verschwendet, sondern auch Synchronisationsprobleme verursacht. Die korrekte Struktur lautete daher:

wp_learner
wp_learner_meta

statt site-übergreifender Präfixe wie wp_1_learner.

Die Rolle der WordPress-Datenbankpräfixe

WordPress nutzt zwei Arten von Präfixen, die in der $wpdb-Klasse verfügbar sind:

• `$wpdb->prefix`: Der Präfix der aktuellen Site. Für Site ID 1 ergibt echo $wpdb->prefix beispielsweise wp_1_.
• `$wpdb->base_prefix`: Der globale Netzwerkpräfix. Hier liefert echo $wpdb->base_prefix einfach wp_.

ACF Pro Custom Tables greifen standardmäßig auf $wpdb->prefix zurück – was für site-spezifische Daten korrekt ist. Doch für netzwerkweite Tabellen wie wp_learner muss stattdessen $wpdb->base_prefix verwendet werden.

Warum ACF Pro Custom Tables hier an Grenzen stoßen

ACF Pro Custom Tables bieten eine strukturierte Möglichkeit, benutzerdefinierte Felder in dedizierten Tabellen zu speichern – statt in der überlasteten wp_postmeta. Das ist besonders für große Projekte mit vielen Feldern vorteilhaft.

Allerdings folgt ACF Pro den WordPress-Multisite-Konventionen: Es erstellt Tabellen wie wp_1_custom_table, basierend auf der aktuellen Site-ID. Das passt perfekt für Daten, die einer einzelnen Website gehören.

Doch im eCoach-Projekt war genau das das Problem. Die Lerner-Daten gehörten dem Netzwerk – nicht einer Site. Ein einfacher Wechsel des Präfixes über ACF-Hooks hätte das Problem nicht gelöst, da die Plugin-Architektur auf site-spezifische Daten ausgelegt ist.

Anpassungen am Plugin-Code? Keine nachhaltige Lösung

Eine naheliegende Idee war, ACF Pro intern so zu modifizieren, dass es $wpdb->base_prefix statt $wpdb->prefix nutzt. Doch das wäre weder wartbar noch zukunftssicher gewesen:

• Plugin-Updates würden die Änderungen überschreiben.
• Eine eigene Fork-Version von ACF Pro wäre nötig – mit allen damit verbundenen Risiken.

ACF Pro funktioniert wie designed. Das Problem lag nicht im Plugin selbst, sondern in der Diskrepanz zwischen Plugin-Architektur und Projektanforderung.

Die Lösung: ACF als Frontend, benutzerdefinierte Logik als Backend

Statt gegen ACF zu arbeiten, wurde es als komfortable Benutzeroberfläche beibehalten – während eine eigene Code-Schicht die netzwerkweiten Tabellen verwaltete. Der Ansatz bestand aus drei Komponenten:

1. Netzwerkweite Tabellen erstellen

Ein benutzerdefiniertes Plugin erzeugte die Tabellen wp_learner und wp_learner_meta mit dem Präfix $wpdb->base_prefix. Diese Tabellen existierten nur einmal im gesamten Netzwerk.

1. ACF-Hooks als Brücke nutzen

Zwei zentrale Hooks verbanden ACF mit den benutzerdefinierten Tabellen:

• `acf/load_value`: Liest Feldwerte aus der wp_learner_meta beim Laden eines Formulars.
• `acf/save_post`: Speichert Änderungen direkt in den netzwerkweiten Tabellen zurück.

   add_filter('acf/load_value', 'load_learner_data_from_network_table', 10, 3);
   add_action('acf/save_post', 'save_learner_data_to_network_table', 20);

1. Benutzerdefinierte Logik für Datenintegrität

Zusätzliche Validierungen und Beziehungen zwischen Lernern und Sites wurden in der Plugin-Schicht implementiert, um Konsistenz zu gewährleisten.

Warum dieser Ansatz zukunftssicher ist

Die Lösung bietet mehrere Vorteile:

• Wartbarkeit: Keine Modifikation von ACF Pro – Updates bleiben möglich.
• Skalierbarkeit: Die Architektur lässt sich leicht auf weitere netzwerkweite Entitäten erweitern.
• Performance: Dedizierte Tabellen reduzieren die Last auf wp_postmeta und verbessern die Abfragegeschwindigkeit.
• Flexibilität: Die Plugin-Schicht kann um zusätzliche Logik wie Caching oder Datenaggregation erweitert werden.

Für Projekte, bei denen ACF Pro Custom Tables mit netzwerkweiten Daten kollidieren, ist dies ein bewährter Workflow: Nutze das Plugin für die Benutzerfreundlichkeit – aber baue die zugrundeliegende Architektur selbst, um die Kontrolle über die Datenhoheit zu behalten.

Fazit: Architektur vor Plugin – aber mit dem richtigen Kompromiss

WordPress Multisite erfordert klare Entscheidungen über Datenhoheit. ACF Pro Custom Tables sind mächtig, aber nicht universell einsetzbar. Wenn die Anforderungen des Projekts von den Standard-Konventionen abweichen, ist ein hybrider Ansatz oft der beste Weg.

Dieses Projekt zeigt: Manchmal liegt die Lösung nicht darin, ein Plugin zu verbiegen – sondern darin, seine Stärken mit einer maßgeschneiderten Architektur zu verbinden. So entsteht ein System, das sowohl performant als auch pflegeleicht ist – und vor allem den Anforderungen der Nutzer entspricht.