The Challenge: Building a WordPress admin dashboard to efficiently display Google Analytics data from approximately 900 blogs spread across 25 multisite instances. The key was to overcome the performance hurdles inherent in processing such a large dataset.
This article details the development process, highlighting key decisions and challenges encountered. We'll explore the WordPress REST API, the PHP vs. JavaScript debate, production environment limitations, security considerations, database design, and even the role of AI.
Before diving in, let's clarify some terms:
The solution involved a single WordPress plugin installed on both the dashboard site and all 25 client sites. This plugin has two main functions:
The WordPress REST API was central to this project. Its extensibility allowed the creation of custom endpoints to expose the necessary data.
Code Snippet: API Endpoint Registration
<?php [...] function register(\WP_REST_Server $server) { $endpoints = $this->get(); foreach ($endpoints as $endpoint_slug => $endpoint) { register_rest_route( $endpoint['namespace'], $endpoint['route'], $endpoint['args'] ); } } // ... (rest of the endpoint definitions) ...
Initially, a PHP-based approach was considered. However, synchronous PHP processing and server-side execution time limits made this impractical. JavaScript's asynchronous capabilities offered a superior solution, enabling concurrent data retrieval from all sites.
The JavaScript implementation significantly reduced data retrieval time: from an estimated 925 seconds (synchronous) to approximately 2 seconds (asynchronous). However, browser and server request limits necessitated a 150-millisecond delay between requests.
Code Snippet: Asynchronous Data Fetching
async function getBlogsDetails(blogs) { let promises = []; blogs.forEach((blog, index) => { // ... (code for delayed fetch requests) ... }); // ... (code for Promise.all and error handling) ... }
The PHP endpoints and JavaScript code were integrated using wp_localize_script()
, seamlessly passing endpoint URLs and other necessary data to the JavaScript.
Security was addressed through application passwords for API authentication and CORS (Cross-Origin Resource Sharing) headers to allow cross-domain requests from the dashboard site to the client sites. The principle of least privilege was followed, restricting CORS access only to necessary endpoints.
Code Snippet: CORS Header Implementation
<?php [...] function register(\WP_REST_Server $server) { $endpoints = $this->get(); foreach ($endpoints as $endpoint_slug => $endpoint) { register_rest_route( $endpoint['namespace'], $endpoint['route'], $endpoint['args'] ); } } // ... (rest of the endpoint definitions) ...
To improve performance, data is cached in a custom database table on the dashboard site, utilizing a relational database model. The database schema was initially designed using DocBlocks and then refined with the assistance of an LLM.
Code Snippet: Database Table Creation SQL
async function getBlogsDetails(blogs) { let promises = []; blogs.forEach((blog, index) => { // ... (code for delayed fetch requests) ... }); // ... (code for Promise.all and error handling) ... }
The MVP is functional, providing valuable insights into blog traffic patterns. Future improvements could include using a modern JavaScript framework and exploring serverless solutions like AWS Lambda for improved scalability and performance. The use of cron jobs for pre-emptive data compilation is also a potential enhancement.
This article provides a high-level overview of the development process. The specific challenges and solutions encountered offer valuable insights for developers working with large-scale WordPress multi-multisite deployments.
The above is the detailed content of WordPress Multi-Multisite: A Case Study. For more information, please follow other related articles on the PHP Chinese website!