How to build scalable WordPress networks with ACF Pro and custom tables

When designing a learner management system for a WordPress Multisite network, developers often face a critical architectural decision: Should learner data be segmented per site or shared across the entire network? This question goes beyond table naming conventions—it defines how data ownership, scalability, and user experience are structured in a multisite environment.

Why data ownership matters in WordPress Multisite

WordPress Multisite isn’t just a collection of independent websites sharing the same codebase. It’s a unified network where certain data types belong to individual sites while others logically belong to the entire ecosystem. Understanding this distinction is essential when building features like learner profiles that may interact with multiple sites within the network.

For example, a learner’s progress report or personal details might need to be accessible network-wide, while site-specific content—such as course materials or local announcements—should remain isolated to individual subsites. Misclassifying this ownership can lead to data duplication, synchronization errors, and unnecessary complexity.

How WordPress prefixes determine table scope

WordPress uses database prefixes to organize data, and Multisite extends this system by appending site identifiers to prefixes. The $wpdb object exposes two key properties for developers:

// Current site prefix (e.g., wp_1_, wp_2_)
global $wpdb;
echo $wpdb->prefix;

// Network-wide prefix (e.g., wp_)
echo $wpdb->base_prefix;

When ACF Pro creates custom tables in a Multisite setup, it defaults to using $wpdb->prefix, which ties the table to the current subsite. This behavior aligns with ACF’s design philosophy—custom fields typically belong to specific posts or pages. However, when your project requires shared tables like wp_learner instead of wp_1_learner, this default behavior falls short.

The ACF Pro Custom Tables limitation

ACF Pro Custom Tables offer performance benefits by storing field data in dedicated tables rather than the wp_postmeta table. Yet, in a Multisite context, they follow the same site-specific logic as standard ACF fields. This means:

• A custom table created on Site 1 becomes wp_1_custom_table
• A learner record created there doesn’t automatically appear on Site 2
• Editors must manage duplicate entries across subsites

This architecture works well for site-local data but fails for network-level entities like learners, where consistency and accessibility are critical.

Rebuilding the architecture without breaking ACF’s workflow

Rather than modifying ACF’s core behavior—an approach that risks plugin updates and long-term maintenance—developers can layer custom logic on top. The solution combines ACF’s user-friendly interface with a purpose-built storage layer:

1. Create shared network tables using $wpdb->base_prefix to ensure tables like wp_learner and wp_learner_meta exist once for the entire network.

1. Bridge ACF hooks to connect the familiar field editor with your custom backend. Use acf/load_value to fetch learner data from the shared table when an editor opens a field group.

1. Redirect saves with acf/save_post to store updates back into the network-level table, not the site-specific meta.

This strategy preserves ACF’s intuitive interface for clients while enabling the scalable, network-wide architecture the project demands.

Best practices for multisite data design

Before finalizing your approach, evaluate these considerations:

• Data lifecycle: Will records be created once and reused, or generated per site?
• Performance impact: Shared tables reduce duplication but may increase query load on large networks.
• Plugin compatibility: Some plugins assume site-local data; test thoroughly.
• Backup and migration: Network-level tables complicate individual site backups—document your process.

By aligning your database structure with the actual ownership of the data, you avoid technical debt and ensure scalability as your network grows.

Looking ahead, WordPress’s evolving multisite capabilities and ACF’s expanding features may simplify this challenge. For now, thoughtful architecture and strategic use of hooks provide the most reliable path to success.