7.1 Staging

Link to chapter 1

You can create a staging site by visiting the Staging tab of your Hosting Hub. Simply follow the prompts there to create and access your new staging site, which is a full copy of your live site. Perfect for trying out new plugins or themes, proofing content changes, and other development work.


Important Notes About Staging

  • Password Protection is required for staging to help ensure that staging sites aren’t indexed by search engines and that your staging site is not visited by the public. The password is not the same as any WordPress user account and can be set from your Hosting Hub.
  • Object Cache is not enabled on staging sites. This will make staging sites a bit slower than your production sites but helps make development easier.
  • You can sync a new copy of your production site to your staging site at any time.
  • When you push a copy of the staging site to your production site, we will automatically make a backup of your production site first. This helps with fast recovery should you need it.
  • Staging uses an incremental clone of your production filesystem. This means that it normally uses very little of your storage space. Only new/changed files on staging, or deleted files on production will increase the amount of storage used by staging. And doing a fresh sync from production will reset that to zero again.
  • Staging is given limited server resources prevent it from adversely affecting your production site. This can make staging run slightly slower, and in rare cases cause errors with some plugins that demand lots of resources.

7.2 Password Protection

Link to chapter 2

You have the option of enabling ‘Password Protection’ on any site. This is useful when developing a new site that you don’t want yet publicly available on the web. You can share the username and password with clients or colleagues too.

Password Protection uses Basic HTTP Authentication and does not use any WordPress usernames or login details.

7.3 Object Cache

Link to chapter 3

We leverage Object Cache at the database level, and this is enabled by default on all sites we host. Object Cache improves performance by minimizing server load related to queries that are frequently called by WordPress, plugins, and themes. Because of this, you may need to clear Object Cache from your Hosting Hub after using a plugin that interacts directly with the database in ways outside of normal WordPress guidelines. Or if you make changes directly in your database using PHPMyAdmin.

To clear cache, visit the Tools menu item in your Hosting Hub.

7.4 Analytics

Link to chapter 4

This guide covers how to locate and understand the analytics data we provide for all sites we host.

After reading this guide, if you still have questions regarding how to make the most of the analytics data we provide, don’t hesitate to start a live chat with our hosting support Superheroes or submit a support ticket using the Support tab of your WPMU Dev Dashboard.

Analytics Overview

Our server-side analytics track key traffic and performance indicators for each site we host. Understanding how this data is collected is critical to developing strategies for your sites, as well as measuring the effectiveness of those strategies over time.

This document covers:

Locating Your Hosting Analytics Data
Defining Visits and Pageviews
Server Analytics vs Google Analytics and Jetpack
Understanding Bandwidth
Estimating Bandwidth Needs
Avoiding Bandwidth-related Downtime

Locating Your Hosting Analytics Data

To locate your Hosting Analytics data, begin in The Hub and click the Hosting tab.

Click the domain name of any site to access that site’s Hosting Overview.

NOTE: Storage usage data is displayed with your Analytics data. See our Storage documentation for a detailed explanation of how we calculate storage usage, including how production, staging, and backups impact storage capacity.

The Quickstats display you see in the Hosting Overview displays 30 days of data regarding visitors, pageviews and bandwidth usage.

Click Analytics to access more detailed graphs of your traffic and bandwidth stats.

Hover over any point on the expanded graphs to see the data for a specific day.

Defining Visits and Pageviews

In simplest terms, Visits are the number of unique IP addresses that accessed your site during the past 30 days, minus identifiable bot traffic and static activity, such as image hotlinking. We exclude static activity because most of the time it doesn’t result in a complete page load.

The Pageviews stat is precisely what the name implies: the total number of times your site’s pages were viewed during any 30-day period. A single visit may involve multiple pageviews.

In practice, it works like this: A unique IP address accesses your site and fully loads a page. That’s a visit and a pageview. If that same IP address then loads another page on your site, it’s not a new visit, but it is a new pageview.

The Visitors stats displayed in the Analytics Overview include both the total number of unique visits to your site during the past 30 days (646 in the example below), and the average number of visitors per day (21 in the example below).

The Pageviews stats displayed in the Analytics Overview include both the total number of pageviews during the past 30 days (1,292 in the example below), and the average number of pageviews per day (42 in the example below).

Server Analytics vs Google Analytics and Jetpack

One of the most common questions regarding our Hosting Analytics is: Why do my Hosting Analytics stats differ from those provided by Google Analytics or Jetpack?

Our server-side stats will always differ from services like Google Analytics (GA) and Jetpack, also known as third-party analytics, because our servers track activity by IP address, whereas third-party services do so by setting a cookie.

Every IP address that accesses your site is recorded in our server logs. We exclude activity that doesn’t meet certain criteria and display the results as Visitors and Pageviews on the Analytics page of your Hosting Overview. The criteria for a legitimate visit is described below under Defining Visits and Pageviews.

For GA or Jetpack to work, a JavaScript file must be downloaded to the visitor’s browser and executed. If the JavaScript file is executed properly the browser will send a request to the third-party servers, and all the activity involved with that visit —known as a session— is recorded. If anything prevents that JavaScript file from executing properly, however, the session will not be recorded.

It’s as simple as that. IP tracking records everything; third-party tracking doesn’t.

For example, if cookies, JavaScript, or images are disabled in the visitor’s browser or the visitor clicks out of a page before the JavaScript file executes, GA or Jetpack won’t record the session, but our servers will.

Another example, specific to GA, involves the tracking codes which must be present on any page you want tracked. If a tracking code is incorrect or absent from a given landing page, visits to that page will be recorded by our servers but not by GA.

Finally, there are bots, and while not all bots are bad bots, they do not reflect real human traffic, so we try not to count them. We maintain a list of hundreds of known bot agents and exclude them from your traffic stats. GA and Jetpack also will ignore identifiable bot traffic if you tell them to. Still, if a bot successfully spoofs a legitimate user from time to time, that can contribute to discrepancies in your stats.

To be clear, we’re not suggesting that GA and Jetpack aren’t great services. They are. However, some users find configuring GA overly burdensome or are wary of JavaScript tracking for security reasons. For these users, our server stats provide a reliable view of site activity.

Many users find configuring Google Analytics intimidating, which is why we developed our plugin Google Analytics +. The plugin walks you through configuring GA for either a single site or multisite network and displays your analytics data in your site or network dashboard.

Get Google Analytics +

Understanding Bandwidth

The bandwidth provided with your hosting plan represents the maximum amount of data that can be transferred to and from your site or network at any given time.

Your bandwidth stats are displayed along with your traffic stats in the Analytics Overview to make it easy to analyze how site activity impacts your bandwidth usage.

The Bandwidth stats displayed in the Analytics Overview include both the total bandwidth used during the past 30 days (646.4 MB in the example below) and the average bandwidth used per day (21.5 MB in the example below).

The classic bandwidth analogy is that of a highway, where the highway is your available bandwidth and the cars are data. Most of the time traffic moves smoothly, entering and exiting the highway with ease. If too many cars enter the highway at one time, however, traffic backs up.

We do not set hard limits on site traffic, but sites that exceed their hosting plans’ recommended traffic levels will experience performance issues. That’s why we provide recommended visit levels for each plan to help you determine which plan will be right for you.

Estimating Bandwidth Needs

It is difficult to predict how much bandwidth you need unless you are an experienced web admin. Usually, at least a couple of months of accumulated data are required to make a reliable estimate. Once you have some good data to work with, calculating your bandwidth requirements is relatively easy.

If you manage multiple stand-alone sites on one account or a multisite network the following calculations must include all sites.

First, multiply your average daily visits by the average pageviews per visitor. For sites we host, these stats are available in the Analytics Overview.

Next, multiply the results from the first step by your site’s average page size. Calculating average page size can be accomplished simply with an online site analyzer like GTmetrix.

If your site offers downloads then you’ll need to multiply how many downloads occur each month by the average file size. Add that figure to the total from the first two steps.

The result of these calculations is your minimum monthly bandwidth needs, the operative word being minimum. You should always have more bandwidth than you need to avoid performance issues or even outages when your site experiences a surge in traffic.

We recommend maintaining at least twice the minimum required bandwidth because surges in traffic tend to be exponential. The last thing you want is performance issues when your site is “hot”. Not only do you miss the chance to attract new visitors, but you also risk turning off existing users.

If we host your site you’ve already taken an important step toward avoiding bandwidth-related downtime because our hosting plans do not skimp on bandwidth. Even our Bronze plan provides 1TB of bandwidth.

Here are some other steps you can take:

Monitor your bandwidth – You can’t anticipate problems if you aren’t paying attention. Periodically check your bandwidth usage stats in the Analytics Overview, paying particular attention to periods of peak usage.

Design a clean site – Clunky themes, excess JavaScript files, and even plugins you no longer need create extra data that your bandwidth is trying to transfer. Our Hummingbird Pro plugin, available free for all WPMU Dev members, will identify and offer solutions to most of your site’s inefficiencies. Also, read Optimizing Your WordPress Database – A Complete Guide to gain a thorough understanding of your WordPress database and how to maintain it at peak efficiency over time.

Optimize Images – Images are critical to an attractive site, but they can bloat a site faster than just about anything else. Our Smush Pro image optimization plugin can automatically optimize and resize every image in any directory the moment it’s uploaded, saving space and bandwidth. Read The Ultimate Guide to Image Optimization to gain a thorough understanding of the importance of image optimization.

Host Videos Elsewhere – Hosting audio and videos files is rarely worth the space they require. Not only do they eat up resources, but they also increase your backup size tremendously, making it difficult to restore WordPress from backup. Instead, you should use an audio and video hosting service like YouTube, Vimeo, SoundCloud, etc.

Use a CDN – A CDN, or a Content Delivery Network, is a cluster of servers located in data centers around the world which specialize in caching content to improve site speed and reduce the burden on your the servers that actually host your site. While a CDN, like Cloudflare, might be overkill for the average blog, large multisite networks and e-commerce sites are relying on them more and more to reduce the chances of bandwidth-related outages. Read Why You Should Be Using a CDN to help you determine if a CDN is right for you.

There are 4 different logs available to you under the Logs tab of your Hosting Hub. The PHP Error Log, Access Log, Slow Log, and Audit Log.

You can download each log’s history as a CSV file using the Download link in the upper right corner.

Please start a chat with our support team if there is anything in your logs that you aren’t sure about or need help with.


7.6 PHP Versions

Link to chapter 6

It is our policy to only provide support for the latest supported PHP versions. This is both to make sure our sites are secure, and to provide you with the fastest most performant hosting service we can!

Currently we default all newly created sites to the latest release of PHP 7.3. Occasionally some third party plugins may be out of date and cause issues with the latest version of PHP. In that case you can look for updates, alternatives, or worst case we do support downgrading your PHP version to older ones that still provide security patches (currently PHP 7.2).

To upgrade or downgrade your PHP version, you can simply visit the hosting Hub, choose your site, and click the edit icon next to PHP Version.

If you want to test your site’s compatibility with the latest version of PHP before upgrading, you can upgrade PHP first in your staging environment via the “Staging” tab and test the functionality there first.

7.7 wp-config.php Constants Protection

Link to chapter 7

Our hosting environments are designed to provide the best WordPress experience possible, so many of the workarounds members may have employed with other hosts are completely unnecessary and are automatically filtered.

Some wp-config.php modifications actually conflict with our system and will adversely affect both member sites and our hosting environments. These include cron jobs and modifications to the WordPress file system or memory limitations.

Cron Jobs

To ensure your scheduled tasks run on time, every time, WPMU DEV hosting environments utilize server-side crons (crontab) by default and call the WordPress scheduling system via WP-CLI every 5 minutes, eliminating the need for alternative cron usage or external services.

File System

Our hosting environments leverage the default WordPress file system to achieve a sustainable balance between performance, security and stability. We understand that members may have been compelled to modify the file system to compensate for the shortcomings of other hosts, but those modifications are not necessary with WPMU DEV hosting and can cause significant issues server-side. Therefore, we do not allow modifications to the wp-content name directory via FS_constants like FTP.

Memory Limits

WPMU DEV hosting allows memory limits (WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT) of 256MB for Bronze and Silver plans, while Gold and Platinum plans are allowed 512MB.

Modifications to the following constants will be removed:



File Permissions



Modifications to the following constants will be filtered: