{"id":382697,"date":"2024-11-27T09:09:14","date_gmt":"2024-11-27T16:09:14","guid":{"rendered":"https:\/\/css-tricks.com\/?p=382697"},"modified":"2024-11-27T09:09:20","modified_gmt":"2024-11-27T16:09:20","slug":"wordpress-multi-multisite-a-case-study","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/wordpress-multi-multisite-a-case-study\/","title":{"rendered":"WordPress Multi-Multisite: A Case Study"},"content":{"rendered":"\n

The mission:<\/strong> Provide a dashboard within the WordPress admin area for browsing Google Analytics data for all your blogs.<\/p>\n\n\n\n

The catch?<\/strong> You\u2019ve got about 900 live blogs, spread across about 25 WordPress multisite instances. Some instances have just one blog, others have as many as 250. In other words, what you need is to compress a data set that normally takes a very long time to compile into a single user-friendly screen.<\/p>\n\n\n\n\n\n\n\n

The implementation details are entirely up to you, but the final result should look like this Figma comp:<\/p>\n\n\n\n

\"\" — Design courtesy of the incomparable Brian Biddle<\/a>.<\/figcaption><\/figure>\n\n\n\n
I want to walk you through my approach and some of the interesting challenges I faced coming up with it, as well as the occasional nitty-gritty detail in between. I\u2019ll cover topics like the WordPress REST API, choosing between a JavaScript or PHP approach, rate\/time limits in production web environments, security, custom database design \u2014 and even a touch of AI. But first, a little orientation.<\/p>\n\n\n
Let\u2019s define some terms<\/h3>\n\n\n
We\u2019re about to cover a lot of ground, so it\u2019s worth spending a couple of moments reviewing some key terms we\u2019ll be using throughout this post.<\/p>\n\n\n
What is WordPress multisite?<\/h4>\n\n\n
WordPress Multisite<\/a> is a feature of WordPress core \u2014 no plugins required \u2014 whereby you can run multiple blogs (or websites, or stores, or what have you) from a single WordPress installation. All the blogs share the same WordPress core files, wp-content folder, and MySQL database. However, each blog gets its own folder within wp-content\/uploads for its uploaded media, and its own set of database tables for its posts, categories, options, etc. Users can be members of some or all blogs within the multisite installation.<\/p>\n\n\n
What is WordPress multi-<\/em>multisite?<\/h4>\n\n\n
It\u2019s just a nickname for managing multiple instances of WordPress multisite. It can get messy to have different customers share one multisite instance, so I prefer to break it up so that each customer has their own multisite, but they can have many blogs within their multisite.<\/p>\n\n\n
So that\u2019s different from a \u201cNetwork of Networks\u201d?<\/h4>\n\n\n
It\u2019s apparently possible to run multiple instances of WordPress multisite against the same WordPress core installation. I\u2019ve never looked into this, but I recall hearing about it over the years. I\u2019ve heard the term \u201cNetwork of Networks\u201d and I like it, but that is not the scenario I\u2019m covering in this article.<\/p>\n\n\n
Why do you keep saying \u201cblogs\u201d? Do people still blog?<\/h4>\n\n\n
You betcha! And people read them, too. You\u2019re reading one right now. Hence, the need for a robust analytics solution. But this article could just as easily be about any sort of WordPress site. I happen to be dealing with blogs, and the word \u201cblog\u201d is a concise way to express \u201ca subsite within a WordPress multisite instance\u201d.<\/p>\n\n\n\n
One more thing: In this article, I\u2019ll use the term dashboard site<\/strong> to refer to the site from which I observe the compiled analytics data. I\u2019ll use the term **client sites<\/strong> to refer to the 25 multisites I pull data from.<\/p>\n\n\n**
My implementation<\/h3>\n\n\n
My strategy was to write one WordPress plugin that is installed on all 25 client sites, as well as on the dashboard site. The plugin serves two purposes:<\/p>\n\n\n\n
\n
Expose data at API endpoints of the client sites<\/li>\n\n\n\n
Scrape the data from the client sites from the dashboard site, cache it in the database, and display it in a dashboard.<\/li>\n<\/ul>\n\n\n
The WordPress REST API is the Backbone<\/h4>\n\n\n
The WordPress REST API is my favorite part of WordPress. Out of the box, WordPress exposes default WordPress *stuff<\/em> like posts, authors, comments, media files, etc., via the WordPress REST API. You can see an example of this by navigating to `\/wp-json<\/code> from any WordPress site,`* *`including CSS-Tricks<\/a>. Here\u2019s the REST API root for the WordPress Developer Resources site<\/a>:<\/p>\n\n\n\n`*
The root URL for the WordPress REST API exposes structured JSON data, such as this example from the WordPress Developer Resources website.<\/figcaption><\/figure>\n\n\n\nWhat\u2019s so great about this? WordPress ships with everything developers need to extend the WordPress REST API and publish custom endpoints<\/a>. Exposing data via an API endpoint is a fantastic way to share it with other websites that need to consume it, and that\u2019s exactly what I did:<\/p>\n\n\n\n \n \n Open the code <\/summary>\n \n\n\n<?php\n\n[...]\n\nfunction register(\\WP_REST_Server $server) {\n $endpoints = $this->get();\n\n foreach ($endpoints as $endpoint_slug => $endpoint) {\n register_rest_route(\n $endpoint['namespace'],\n $endpoint['route'],\n $endpoint['args']\n );\n }\n}\n\nfunction get() {\n\n $version = 'v1';\n\n return array(\n \n 'empty_db' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/empty_db',\n 'args' => array(\n 'methods' => array( 'DELETE' ),\n 'callback' => array($this, 'empty_db_cb'),\n 'permission_callback' => array( $this, 'is_admin' ),\n ),\n ),\n\n 'get_blogs' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/get_blogs',\n 'args' => array(\n 'methods' => array('GET', 'OPTIONS'),\n 'callback' => array($this, 'get_blogs_cb'),\n 'permission_callback' => array($this, 'is_dba'),\n ),\n ),\n\n 'insert_blogs' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/insert_blogs',\n 'args' => array(\n 'methods' => array( 'POST' ),\n 'callback' => array($this, 'insert_blogs_cb'),\n 'permission_callback' => array( $this, 'is_admin' ),\n ),\n ),\n\n 'get_blogs_from_db' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/get_blogs_from_db',\n 'args' => array(\n 'methods' => array( 'GET' ),\n 'callback' => array($this, 'get_blogs_from_db_cb'),\n 'permission_callback' => array($this, 'is_admin'),\n ),\n ), \n\n 'get_blog_details' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/get_blog_details',\n 'args' => array(\n 'methods' => array( 'GET' ),\n 'callback' => array($this, 'get_blog_details_cb'),\n 'permission_callback' => array($this, 'is_dba'),\n ),\n ), \n\n 'update_blogs' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/update_blogs',\n 'args' => array(\n 'methods' => array( 'PATCH' ),\n 'callback' => array($this, 'update_blogs_cb'),\n 'permission_callback' => array($this, 'is_admin'),\n ),\n ), \n\n );\n}<\/code><\/pre>\n\n\n<\/details>\n\n\nWe don\u2019t need to get into every endpoint’s details, but I want to highlight one thing. First, I provided a function that returns all my endpoints in an array. Next, I wrote a function to loop through the array and register each array member as a WordPress REST API endpoint. Rather than doing both steps in one function, this decoupling allows me to easily retrieve the array of endpoints in other parts of my plugin to do other interesting things with them, such as exposing them to JavaScript. More on that shortly.<\/p>\n\n\n\nOnce registered, the custom API endpoints are observable in an ordinary web browser like in the example above, or via purpose-built tools for API work, such as Postman<\/a>:<\/p>\n\n\n\n <\/figure>\n\n\nPHP vs. JavaScript<\/h4>\n\n\nI tend to prefer writing applications in PHP whenever possible, as opposed to JavaScript, and executing logic on the server, as nature intended, rather than in the browser. So, what would that look like on this project?<\/p>\n\n\n\n\nOn the dashboard site, upon some event, such as the user clicking a \u201crefresh data\u201d button or perhaps a cron job, the server would make an HTTP request to each of the 25 multisite installs.<\/li>\n\n\n\nEach multisite install would query all of its blogs and consolidate its analytics data into one response per multisite.<\/li>\n<\/ul>\n\n\n\nUnfortunately, this strategy falls apart for a couple of reasons:<\/p>\n\n\n\n\nPHP operates synchronously, meaning you wait for one line of code to execute before moving to the next. This means that we\u2019d be waiting for all 25 multisites to respond in series. That\u2019s sub-optimal.<\/li>\n\n\n\nMy production environment has a max execution limit of 60 seconds, and some of my multisites contain hundreds of blogs. Querying their analytics data takes a second or two per blog.<\/li>\n<\/ul>\n\n\n\nDamn. I had no choice but to swallow hard and commit to writing the application logic in JavaScript. Not my favorite, but an eerily elegant solution for this case:<\/p>\n\n\n\n\nDue to the asynchronous nature of JavaScript, it pings all 25 Multisites at once.<\/li>\n\n\n\n The endpoint on each Multisite returns a list of all the blogs on that Multisite.<\/li>\n\n\n\n The JavaScript compiles that list of blogs and (sort of) pings all 900 at once.<\/li>\n\n\n\nAll 900 blogs take about one-to-two seconds to respond concurrently.<\/li>\n<\/ul>\n\n\n\nHoly cow, it just went from this:<\/p>\n\n\n\n( 1 second per Multisite * 25 installs ) + ( 1 second per blog * 900 blogs ) = roughly 925 seconds to scrape all the data.<\/code><\/pre>\n\n\n\nTo this:<\/p>\n\n\n\n 1 second for all the Multisites at once + 1 second for all 900 blogs at once = roughly 2 seconds to scrape all the data.<\/code><\/pre>\n\n\n\nThat is, in theory. In practice, two factors enforce a delay:<\/p>\n\n\n\n \nBrowsers have a limit as to how many concurrent HTTP requests they will allow, both per domain and regardless of domain. I\u2019m having trouble finding documentation on what those limits are. Based on observing the network panel in Chrome while working on this, I\u2019d say it\u2019s about 50-100.<\/li>\n\n\n\n Web hosts have a limit on how many requests they can handle within a given period, both per IP address and overall. I was frequently getting a \u201c429; Too Many Requests\u201d response<\/a> from my production environment, so I introduced a delay of 150 milliseconds between requests. They still operate concurrently, it\u2019s just that they\u2019re forced to wait 150ms per blog. Maybe \u201cstagger\u201d is a better word than \u201cwait\u201d in this context:<\/li>\n<\/ol>\n\n\n\n\n \n Open the code <\/summary>\n \n\nasync function getBlogsDetails(blogs) {\n let promises = [];\n\n \/\/ Iterate and set timeouts to stagger requests by 100ms each\n blogs.forEach((blog, index) => {\n if (typeof blog.url === 'undefined') {\n return;\n }\n\n let id = blog.id;\n const url = blog.url + '\/' + blogDetailsEnpointPath + '?uncache=' + getRandomInt();\n\n \/\/ Create a promise that resolves after 150ms delay per blog index\n const delayedPromise = new Promise(resolve => {\n setTimeout(async () => {\n try {\n const blogResult = await fetchBlogDetails(url, id);\n \n if( typeof blogResult.urls == 'undefined' ) {\n console.error( url, id, blogResult );\n\n } else if( ! blogResult.urls ) {\n console.error( blogResult );\n \n \n } else if( blogResult.urls.length == 0 ) {\n console.error( blogResult );\n \n } else {\n console.log( blogResult );\n }\n \n resolve(blogResult);\n } catch (error) {\n console.error(`Error fetching details for blog ID ${id}:`, error);\n resolve(null); \/\/ Resolve with null to handle errors gracefully\n }\n }, index * 150); \/\/ Offset each request by 100ms\n });\n\n promises.push(delayedPromise);\n});\n\n \/\/ Wait for all requests to complete\n const blogsResults = await Promise.all(promises);\n\n \/\/ Filter out any null results in case of caught errors\n return blogsResults.filter(result => result !== null);\n}<\/code><\/pre>\n\n\n<\/details>\n\n\nWith these limitations factored in, I found that it takes about 170 seconds to scrape all 900 blogs. This is acceptable because I cache the results, meaning the user only has to wait once at the start of each work session.<\/p>\n\n\n\n The result of all this madness \u2014 this incredible barrage of Ajax calls, is just plain fun to watch:<\/p>\n\n\n\nPHP and JavaScript: Connecting the dots<\/h4>\n\n\nI registered my endpoints in PHP and called them in JavaScript. Merging these two worlds is often an annoying and bug-prone part of any project. To make it as easy as possible, I use wp_localize_script()<\/a><\/code>:<\/p>\n\n\n\n <?php\n\n[...]\n\nclass Enqueue {\n\n function __construct() {\n add_action( 'admin_enqueue_scripts', array( $this, 'lexblog_network_analytics_script' ), 10 );\n add_action( 'admin_enqueue_scripts', array( $this, 'lexblog_network_analytics_localize' ), 11 );\n }\n\n function lexblog_network_analytics_script() {\n wp_register_script( 'lexblog_network_analytics_script', LXB_DBA_URL . '\/js\/lexblog_network_analytics.js', array( 'jquery', 'jquery-ui-autocomplete' ), false, false );\n }\n\n function lexblog_network_analytics_localize() {\n $a = new LexblogNetworkAnalytics;\n $data = $a -> get_localization_data();\n $slug = $a -> get_slug();\n\n wp_localize_script( 'lexblog_network_analytics_script', $slug, $data );\n\n }\n\n \/\/ etc. \n}<\/code><\/pre>\n\n\n\nIn that script, I\u2019m telling WordPress two things:<\/p>\n\n\n\n\nLoad my JavaScript file.<\/li>\n\n\n\nWhen you do, take my endpoint URLs, bundle them up as JSON, and inject them into the HTML document as a global variable for my JavaScript to read. This is leveraging the point I noted earlier where I took care to provide a convenient function for defining the endpoint URLs, which other functions can then invoke without fear of causing any side effects.<\/li>\n<\/ol>\n\n\n\nHere\u2019s how that ended up looking:<\/p>\n\n\n\nThe JSON and its associated JavaScript file, where I pass information from PHP to JavaScript using\u00a0wp_localize_script()<\/code>.<\/figcaption><\/figure>\n\n\nAuth: Fort Knox or Sandbox?<\/h3>\n\n\nWe need to talk about authentication. To what degree do these endpoints need to be protected by server-side logic? Although exposing analytics data is not nearly as sensitive as, say, user passwords, I\u2019d prefer to keep things reasonably locked up. Also, since some of these endpoints perform a lot of database queries and Google Analytics API calls, it\u2019d be weird to sit here and be vulnerable to weirdos who might want to overload my database or Google Analytics rate limits.<\/p>\n\n\n\nThat\u2019s why I registered an application password<\/a> on each of the 25 client sites. Using an app password in php is quite simple. You can authenticate the HTTP requests<\/a> just like any basic authentication scheme.<\/p>\n\n\n\n I\u2019m using JavaScript, so I had to localize them first, as described in the previous section. With that in place, I was able to append these credentials when making an Ajax call:<\/p>\n\n\n\n async function fetchBlogsOfInstall(url, id) {\n let install = lexblog_network_analytics.installs[id];\n let pw = install.pw;\n let user = install.user;\n\n \/\/ Create a Basic Auth token\n let token = btoa(`${user}:${pw}`);\n let auth = {\n 'Authorization': `Basic ${token}`\n };\n\n try {\n let data = await $.ajax({\n url: url,\n method: 'GET',\n dataType: 'json',\n headers: auth\n });\n\n return data;\n\n } catch (error) {\n console.error('Request failed:', error);\n return [];\n }\n}<\/code><\/pre>\n\n\n\nThat file uses this cool function called btoa()<\/code><\/a> for turning the raw username and password combo into basic authentication.<\/p>\n\n\n The part where we say, \u201cOh Right, CORS.\u201d<\/h3>\n\n\nWhenever I have a project where Ajax calls are flying around all over the place, working reasonably well in my local environment, I always have a brief moment of panic when I try it on a real website, only to get errors like this:<\/p>\n\n\n\n<\/figure>\n\n\n\nOh. Right. CORS<\/a>. Most reasonably secure websites do not allow other websites to make arbitrary Ajax requests. In this project, I absolutely do need the Dashboard Site to make many Ajax calls to the 25 client sites, so I have to tell the client sites to allow CORS:<\/p>\n\n\n\n <?php\n\n \/\/ ...\n\n function __construct() {\n add_action( 'rest_api_init', array( $this, 'maybe_add_cors_headers' ), 10 );\n}\n\nfunction maybe_add_cors_headers() { \n \/\/ Only allow CORS for the endpoints that pertain to this plugin.\n if( $this->is_dba() ) {\n add_filter( 'rest_pre_serve_request', array( $this, 'send_cors_headers' ), 10, 2 );\n }\n}\n\nfunction is_dba() {\n $url = $this->get_current_url();\n $ep_urls = $this->get_endpoint_urls();\n $out = in_array( $url, $ep_urls );\n \n return $out;\n \n}\n\nfunction send_cors_headers( $served, $result ) {\n\n \/\/ Only allow CORS from the dashboard site.\n $dashboard_site_url = $this->get_dashboard_site_url();\n\n header( \"Access-Control-Allow-Origin: $dashboard_site_url\" );\n header( 'Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization' );\n header( 'Access-Control-Allow-Methods: GET, OPTIONS' );\n return $served;\n \n}\n\n [...]\n\n}<\/code><\/pre>\n\n\n\nYou\u2019ll note that I\u2019m following the principle of least privilege<\/a> by taking steps to only allow CORS where it\u2019s necessary.<\/p>\n\n\n Auth, Part 2: I\u2019ve been known to auth myself<\/h3>\n\n\nI authenticated an Ajax call from the dashboard site to the client sites. I registered some logic on all the client sites to allow the request to pass CORS. But then, back on the dashboard site, I had to get that response from the browser to the server.<\/p>\n\n\n\n The answer, again, was to make an Ajax call to the WordPress REST API endpoint for storing the data. But since this was an actual database write, not merely a read, it was more important than ever to authenticate. I did this by requiring that the current user be logged into WordPress and possess sufficient privileges. But how would the browser know about this?<\/p>\n\n\n\nIn PHP, when registering our endpoints, we provide a permissions callback<\/a> to make sure the current user is an admin:<\/p>\n\n\n\n <?php\n\n\/\/ ...\n\nfunction get() {\n $version = 'v1';\n return array(\n\n 'update_blogs' => array(\n 'namespace' => 'LXB_DBA\/' . $version,\n 'route' => '\/update_blogs',\n 'args' => array(\n 'methods' => array( 'PATCH' ),\n 'callback' => array( $this, 'update_blogs_cb' ),\n 'permission_callback' => array( $this, 'is_admin' ),\n ),\n ),\n \/\/ ...\n ); \n }\n \nfunction is_admin() {\n $out = current_user_can( 'update_core' );\n return $out;\n}<\/code><\/pre>\n\n\n\nJavaScript can use this \u2014 it\u2019s able to identify the current user \u2014 because, once again, that data is localized. The current user is represented by their nonce<\/a>:<\/p>\n\n\n\n async function insertBlog( data ) {\n \n let url = lexblog_network_analytics.endpoint_urls.insert_blog;\n\n try {\n await $.ajax({\n url: url,\n method: 'POST',\n dataType: 'json',\n data: data,\n headers: {\n 'X-WP-Nonce': getNonce()\n }\n });\n } catch (error) {\n console.error('Failed to store blogs:', error);\n }\n}\n\nfunction getNonce() {\n if( typeof wpApiSettings.nonce == 'undefined' ) { return false; }\n return wpApiSettings.nonce;\n}<\/code><\/pre>\n\n\n\nThe wpApiSettings.nonce<\/code> global variable is automatically present in all WordPress admin screens. I didn\u2019t have to localize that. WordPress core did it for me.<\/p>\n\n\nCache is King<\/h3>\n\n\nCompressing the Google Analytics data from 900 domains into a three-minute loading .gif<\/code> is decent, but it would be totally unacceptable to have to wait for that long multiple times per work session. Therefore I cache the results of all 25 client sites in the database of the dashboard site.<\/p>\n\n\n\nI\u2019ve written before about using the WordPress Transients API<\/a> for caching data, and I could have used it on this project. However, something about the tremendous volume of data and the complexity implied within the Figma design made me consider a different approach. I like the saying, \u201cThe wider the base, the higher the peak,\u201d and it applies here. Given that the user needs to query and sort the data by date, author, and metadata, I think stashing everything into a single database cell \u2014 which is what a transient is \u2014 would feel a little claustrophobic. Instead, I dialed up E.F. Codd<\/a> and used a relational database model via custom tables:<\/p>\n\n\n\n In the Dashboard Site, I created seven custom database tables, including one relational table, to cache the data from the 25 client sites, as shown in the image.<\/figcaption><\/figure>\n\n\n\nIt\u2019s been years since I\u2019ve paged through Larry Ullman\u2019s career-defining (as in, my career) books<\/a> on database design, but I came into this project with a general idea of what a good architecture would look like. As for the specific details \u2014 things like column types \u2014 I foresaw a lot of Stack Overflow time in my future. Fortunately, LLMs love MySQL and I was able to scaffold out my requirements using DocBlocks<\/a> and let Sam Altman<\/a> fill in the blanks:<\/p>\n\n\n\n \n \n Open the code <\/summary>\n \n\n<?php \n\n\/**\n* Provides the SQL code for creating the Blogs table. It has columns for:\n* - ID: The ID for the blog. This should just autoincrement and is the primary key.\n* - name: The name of the blog. Required.\n* - slug: A machine-friendly version of the blog name. Required.\n* - url: The url of the blog. Required.\n* - mapped_domain: The vanity domain name of the blog. Optional.\n* - install: The name of the Multisite install where this blog was scraped from. Required.\n* - registered: The date on which this blog began publishing posts. Optional.\n* - firm_id: The ID of the firm that publishes this blog. This will be used as a foreign key to relate to the Firms table. Optional.\n* - practice_area_id: The ID of the firm that publishes this blog. This will be used as a foreign key to relate to the PracticeAreas table. Optional.\n* - amlaw: Either a 0 or a 1, to indicate if the blog comes from an AmLaw firm. Required.\n* - subscriber_count: The number of email subscribers for this blog. Optional.\n* - day_view_count: The number of views for this blog today. Optional.\n* - week_view_count: The number of views for this blog this week. Optional.\n* - month_view_count: The number of views for this blog this month. Optional.\n* - year_view_count: The number of views for this blog this year. Optional.\n* \n* @return string The SQL for generating the blogs table.\n*\/\nfunction get_blogs_table_sql() {\n $slug = 'blogs';\n $out = \"CREATE TABLE {$this->get_prefix()}_$slug (\n id BIGINT NOT NULL AUTO_INCREMENT,\n slug VARCHAR(255) NOT NULL,\n name VARCHAR(255) NOT NULL,\n url VARCHAR(255) NOT NULL UNIQUE, \/* adding unique constraint *\/\n mapped_domain VARCHAR(255) UNIQUE,\n install VARCHAR(255) NOT NULL,\n registered DATE DEFAULT NULL,\n firm_id BIGINT,\n practice_area_id BIGINT,\n amlaw TINYINT NOT NULL,\n subscriber_count BIGINT,\n day_view_count BIGINT,\n week_view_count BIGINT,\n month_view_count BIGINT,\n year_view_count BIGINT,\n PRIMARY KEY (id),\n FOREIGN KEY (firm_id) REFERENCES {$this->get_prefix()}_firms(id),\n FOREIGN KEY (practice_area_id) REFERENCES {$this->get_prefix()}_practice_areas(id)\n ) DEFAULT CHARSET=utf8mb4;\";\n return $out;\n}<\/code><\/pre>\n\n\n<\/details>\n\n\nIn that file, I quickly wrote a DocBlock for each function, and let the OpenAI playground spit out the SQL. I tested the result and suggested some rigorous type-checking for values that should always be formatted as numbers or dates, but that was the only adjustment I had to make. I think that\u2019s the correct use of AI at this moment: You come in with a strong idea of what the result should be, AI fills in the details, and you debate with it until the details reflect what you mostly already knew.<\/p>\n\n\nHow it\u2019s going<\/h3>\n\n\nI\u2019ve implemented most of the user stories now. Certainly enough to release an MVP and begin gathering whatever insights this data might have for us:<\/p>\n\n\n\nIt\u2019s working!<\/figcaption><\/figure>\n\n\n\nOne interesting data point thus far: Although all the blogs are on the topic of legal matters (they are lawyer blogs, after all), blogs that cover topics with a more general appeal seem to drive more traffic. Blogs about the law as it pertains to food, cruise ships, germs, and cannabis, for example. Furthermore, the largest law firms on our network don\u2019t seem to have much of a foothold there. Smaller firms are doing a better job of connecting with a wider audience. I\u2019m positive that other insights will emerge as we work more deeply with this.<\/p>\n\n\nRegrets? I\u2019ve had a few.<\/h3>\n\n\nThis project probably would have been a nice opportunity to apply a modern JavaScript framework, or just no framework at all. I like React and I can imagine how cool it would be to have this application be driven by the various changes in state rather than\u2026 drumroll<\/em>\u2026 a couple thousand lines of jQuery!<\/strong><\/p>\n\n\n\nI like jQuery\u2019s ajax()<\/code> method, and I like the jQueryUI autocomplete component<\/a>. Also, there\u2019s less of a performance concern here than on a public-facing front-end. Since this screen is in the WordPress admin area, I\u2019m not concerned about Google admonishing me for using an extra library. And I\u2019m just faster with jQuery. Use whatever you want.<\/p>\n\n\n\n I also think it would be interesting to put AWS to work here and see what could be done through Lambda functions. Maybe I could get Lambda to make all 25 plus 900 requests concurrently with no worries about browser limitations. Heck, maybe I could get it to cycle through IP addresses and sidestep the 429 rate limit as well.<\/p>\n\n\n\n And what about cron?<\/a> Cron could do a lot of work for us here. It could compile the data on each of the 25 client sites ahead of time, meaning that the initial three-minute refresh time goes away. Writing an application in cron, initially, I think is fine. Coming back six months later to debug something is another matter. Not my favorite. I might revisit this later on, but for now, the cron-free implementation meets the MVP goal.<\/p>\n\n\n\n I have not provided a line-by-line tutorial here, or even a working repo for you to download, and that level of detail was never my intention. I wanted to share high-level strategy decisions that might be of interest to fellow Multi-Multisite people. Have you faced a similar challenge? I\u2019d love to hear about it in the comments!<\/p>\n","protected":false},"excerpt":{"rendered":" What’s it look like to create a dashboard within the WordPress admin for analyzing Google Analytics data across 900 blogs across 25 multisite instances? It involves designing a user-friendly interface, leveraging the WordPress REST API, implementing a plugin for data retrieval, and addressing challenges like rate limits and authentication.<\/p>\n","protected":false},"author":229300,"featured_media":382714,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"_share_on_mastodon":"1","_share_on_mastodon_status":"What's it look like to create a dashboard within the WordPress admin for analyzing Google Analytics data across 900 blogs across 25 multisite instances? It's a little nuts and niche but a super interesting use case.\r\n\r\n%permalink%"},"categories":[4],"tags":[264],"class_list":["post-382697","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","tag-wordpress"],"acf":{"show_toc":"No"},"share_on_mastodon":{"url":"https:\/\/mastodon.social\/@csstricks\/113555784287497330","error":""},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2024\/11\/wp-multisite.jpg?fit=1200%2C600&ssl=1","jetpack-related-posts":[{"id":353317,"url":"https:\/\/css-tricks.com\/woocommerce-google-analytics\/","url_meta":{"origin":382697,"position":0},"title":"WooCommerce + Google Analytics","author":"Chris Coyier","date":"October 12, 2021","format":false,"excerpt":"Google Analytics is powerful analytics software. A common way to use it is to just slap the JavaScript snippet on every page template you have and let it collect basic data about unique visitors and pageviews and such. That's useful, but it's also the bare minimum. Say there is an\u2026","rel":"","context":"In "Articles"","block_context":{"text":"Articles","link":"https:\/\/css-tricks.com\/category\/articles\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/woo-google-analytics.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/woo-google-analytics.png?fit=1200%2C600&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/woo-google-analytics.png?fit=1200%2C600&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/woo-google-analytics.png?fit=1200%2C600&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/woo-google-analytics.png?fit=1200%2C600&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":333087,"url":"https:\/\/css-tricks.com\/embedding-an-interactive-analytics-component-with-cumul-io-and-any-web-framework\/","url_meta":{"origin":382697,"position":1},"title":"Embedding an Interactive Analytics Component with Cumul.io and Any Web Framework","author":"Geoff Graham","date":"January 28, 2021","format":false,"excerpt":"In this article, we explain how to build an integrated and interactive data visualization layer into an application with Cumul.io. To do so, we\u2019ve built a demo application that visualizes Spotify Playlist analytics! We use Cumul.io as our interactive dashboard as it makes integration super easy and provides functionality that\u2026","rel":"","context":"In "Sponsored"","block_context":{"text":"Sponsored","link":"https:\/\/css-tricks.com\/category\/sponsored\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/01\/0Uz2iFHvwRHTq4Gnz.gif?fit=1200%2C583&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/01\/0Uz2iFHvwRHTq4Gnz.gif?fit=1200%2C583&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/01\/0Uz2iFHvwRHTq4Gnz.gif?fit=1200%2C583&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/01\/0Uz2iFHvwRHTq4Gnz.gif?fit=1200%2C583&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/01\/0Uz2iFHvwRHTq4Gnz.gif?fit=1200%2C583&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":188084,"url":"https:\/\/css-tricks.com\/sponsor-dash-monitor-website-business-life\/","url_meta":{"origin":382697,"position":2},"title":"Sponsor: Dash – Monitor your Website, Business, & Life","author":"Chris Coyier","date":"November 13, 2014","format":false,"excerpt":"Dash is a website that lets people quickly create real-time dashboards. There are dozens of pre-built widgets for services like Google Analytics, GitHub, Twitter, and Fitbit. Dash also has an API that allows you to share data from Dropbox or the web with custom widgets like Line Charts, Speedometers, or\u2026","rel":"","context":"In "Links"","block_context":{"text":"Links","link":"https:\/\/css-tricks.com\/category\/links\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":152735,"url":"https:\/\/css-tricks.com\/cargo-cult-analytics\/","url_meta":{"origin":382697,"position":3},"title":"Cargo cult analytics","author":"Chris Coyier","date":"October 11, 2013","format":false,"excerpt":"There is a lot to quote in this great article by Stijn Debrouwere: There\u2019s nothing like a dashboard full of data and graphs and trend lines to make us feel like grown ups. ... metrics only make sense when you\u2019re going to do something with them. I\u2019ve never seen a\u2026","rel":"","context":"In "Links"","block_context":{"text":"Links","link":"https:\/\/css-tricks.com\/category\/links\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":16884,"url":"https:\/\/css-tricks.com\/shoptalk-episode-16\/","url_meta":{"origin":382697,"position":4},"title":"ShopTalk Episode 16","author":"Chris Coyier","date":"April 29, 2012","format":false,"excerpt":"Dave and I were joined by Ian Stewart, a Theme Wrangler at Automattic for WordPress.com (he's probably thinking about WordPress themes right this very minute). We talked about WordPress multisite, training clients in WordPress, database syncing, team productivity, and more.","rel":"","context":"In "Links"","block_context":{"text":"Links","link":"https:\/\/css-tricks.com\/category\/links\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":353243,"url":"https:\/\/css-tricks.com\/embedded-analytics-made-simple-with-cumul-io-integrations\/","url_meta":{"origin":382697,"position":5},"title":"Embedded Analytics Made Simple With Cumul.io Integrations","author":"Cumul.io","date":"October 14, 2021","format":false,"excerpt":"Browse through SaaS communities on Twitter, LinkedIn, Reddit, Discord, you name it and you\u2019ll see a common theme appear in many of them. That theme can go by many names: BI, analytics, insights and so on. It\u2019s natural, we do business, collect data, we succeed or fail. We want to\u2026","rel":"","context":"In "Sponsored"","block_context":{"text":"Sponsored","link":"https:\/\/css-tricks.com\/category\/sponsored\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/featured.png?fit=1201%2C601&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/featured.png?fit=1201%2C601&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/featured.png?fit=1201%2C601&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/featured.png?fit=1201%2C601&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/featured.png?fit=1201%2C601&ssl=1&resize=1050%2C600 3x"},"classes":[]}],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/382697","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/229300"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=382697"}],"version-history":[{"count":8,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/382697\/revisions"}],"predecessor-version":[{"id":382840,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/382697\/revisions\/382840"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/382714"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=382697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=382697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=382697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Let\u2019s define some terms<\/h3>\n\n\nWe\u2019re about to cover a lot of ground, so it\u2019s worth spending a couple of moments reviewing some key terms we\u2019ll be using throughout this post.<\/p>\n\n\n

Let\u2019s define some terms<\/h3>\n\n\n
We\u2019re about to cover a lot of ground, so it\u2019s worth spending a couple of moments reviewing some key terms we\u2019ll be using throughout this post.<\/p>\n\n\n