Quick and Reliable Bug Testing with Cloner for Multisite
Bug testing is super important if you run Multisite. After all, you want your network to actually work for your users. Imagine if you set up a blog at WordPress.com and had trouble setting up a domain or your theme kept resetting. Not cool, right? Now imagine if your users experienced similar issues on your network. Also not cool.
Whether you have set up a local or online site to test out new designs or plugins, it can be difficult and time-consuming to push changes to your live site. Pushing changes to a live site can also make it difficult to track and test bugs. And don’t forget how unprofessional it can look to visitors if they are using your site as you make changes here and there.
On the flip side, local installs can save your users ever seeing temporary changes, but there’s nothing like a live install when it comes to testing out certain functionality, like caching plugins, and letting some friends test out your site to help you improve it.
Why not get the best of both worlds? With our Multisite Privacy plugin, you can have your own private, live site to test out new features and find bugs while controlling and limiting access to people and search engines alike.
And it gets better. By pairing Multisite Privacy with our Cloner plugin you can copy any site in your network in a couple clicks and test your designs and tweaks, then publish your changes to any site in your network when you’re ready, again, in a couple of clicks.
In this tutorial, I’ll show you how to set up Multisite Privacy and Cloner to create a private and exact replica site for testing, and offer tools and plugins to help you maximize and streamline your bug testing process.
To complete the quick and easy bug testing process, you need to install and network activate the Multisite Privacy and Cloner plugins, but before you do, there’s a necessary measure of caution you need to consider.
Since this bug testing process relies on changing the state of your current site, it’s important to backup your entire site, both files and database. If you make a mistake, you can easily restore your site to its former glory.
For more information on making a backup of your site, check out some of our other posts: How to Backup Your WordPress Website (and Multisite) Using Snapshot, Backup Plugins Aren’t About Backing Up, They’re About Restoring and 7 Top Premium and Freemium Backup Plugins Reviewed.
Once all that’s out of the way and you have installed and network activated the plugins, you’re ready to get started.
Cloning a Site for Bug Testing
The Cloner plugin doesn’t actually need any setting up, which is great. Once it’s installed, you can start using it right away.
By default, Cloner copies an entire site, but if there are certain parts you don’t want to clone, you can go to Settings > Cloner to configure the options.
You can uncheck the boxes of content you would rather not include, then click the Save Changes button at the bottom to save your choices.
There are additional selections you can make to clone on a site, including posts, terms, comments, pages, menus and attachments.
Once you are done selecting the settings that work for you, you can choose which site you would like to copy to start your bug testing.
In the super admin dashboard, head over to Sites > All Sites and hover over the site you would like to clone whether it’s your main site or any other one in your network.
Click the Clone link to load a page with some additional settings.
At the top of the page, you should see the address of the site you selected. If you clicked the link to copy the wrong site, you can simply click the Choose a different site link at the top to pick a different site from your network.
When you’re ready to get cloning, the first step is to select the Create a new site radio button under the section called Destination.
Next, enter the URL of your cloned site in relation to the network’s address. Enter your desired extension, but only type in lowercase letters and numbers.
Whether your network is set up to register sub-domains or sub-directories, your cloned site follows suit with the same URL pattern.
Because of the nature of Multisite, you won’t be able to choose the opposite type of domain path. If your current setup doesn’t work for you, check out one of our other articles on changing your network from sub-directories or sub-domains.
Once you have decided on your URL, continue to the next section under Options > Site Title.
You should see three types of site titles to choose from:
- Clone blog title – You can choose to display the exact same title as the original site. No extra characters such as “copy” are added.
- Keep the destination blog title – This option isn’t available for cloning sites. It’s purpose is to keep the blog title you chose for the cloned site when you are replacing a site in the network. This option is covered in more depth a bit later so keep reading.
- Overwrite blog title with – A text field accompanies this radio button. In it, you can create a brand new title for your copied site. You aren’t limited to certain characters so you’re free to type in any title you would like.
The last setting in this section is for Search Engine Visibility. If you want to keep search engines at bay so they can’t crawl your site, check this option.
This helps protect your search engine ranking since duplicate content negatively affects it. It’s important to keep in mind that this option doesn’t guarantee search engines won’t crawl your site – it only discourages them from stopping by.
Don’t worry, though, that’s why you installed the Multisite Privacy plugin since you can fully protect your site that way and it’s also covered next. For now, check the box to help prevent bots from crawling your site.
If the site you would like to clone has many custom tables created from installed plugins like BuddyPress, Pro Sites, and many others, you should also see a third section called Advanced Options.
If you don’t see it, you’re ready to clone your site. Click the Clone Site button at the bottom of the page and sit back while it processes. It typically doesn’t take longer than a couple minutes, but if you are copying a large site, it may take a bit longer so there’s no need to panic.
If you do see another set of options, you can choose which of those custom tables you would like to copy.
In the multi-line text box on the left are all the tables that won’t be included in the cloned site. If you click on a table, it’s transferred to the multi-line text box on the right and is copied.
After clicking on all the tables you want to include in the copied site, you’re ready to click the Clone Site button at the bottom of the page.
Once your new site has been successfully copied, you should be automatically redirected to the dashboard of the newly cloned site.
Setting Up Multisite Privacy
Now you’re ready to make your new, cloned site private. Access your super admin dashboard and go to Settings > Network Settings. Scroll down to the newly available section titled Site Privacy Settings.
This is where you can choose the settings that are applied globally and also if you would like site admins to be able to control their own settings.
In the Available Options, you can choose to:
- Only allow logged in users to see all sites – If you have users already registered and would like them to see all sites in the network, but don’t want any non-logged in users to see sites in the network, check this box.For example, if you have contributors that still need to access the site or other kinds of registered users, this is the option for you.
- Only allow a registered user to see a site for which they are registered – Users must be logged in to see a site, but only sites where they are registered. They won’t be able to see all sites in the network unless they are registered to all of them.This option is helpful if, for example, you house sites for different clients that have a mix of users with different roles that all need to be able to access their site, but you don’t want them to access the sites of your other clients.
- Only allow administrators of a site to view the site for which they are an admin – Any user that doesn’t have an administrator user role won’t be able to view sites in the network. Only admins will be able to view sites, but only for the ones where they have admin access.What if you host different clients’ sites, for example, but each of them should be the only ones to access their own site? This is the option you would choose to accomplish this.
- Allow network administrators to set a single password that any visitors must use to see the site – This options gives access to visitors and users, but only if they know the universal password that super admin has set.This option can be helpful if you would like some of your peers or colleagues to see a site’s progress, but don’t want to give everyone access and also don’t want them all to be required to register in order to see the site.
Under Default Settings, the following global additional radio button options are available:
- Allow all visitors to all sites – This includes any passers-by as well as search engine bots that crawl your site for information to adjust your ranking.
- Block search engines from all sites, but allow normal visitors to see all sites – This discourages search engine bots from crawling the site, but it’s up to them to honor the request. Regular passers-by can still view all sites in the network like normal.
- Only allow logged in users to see all sites – No matter what the user role, a registered user can view all the sites in the network.
- Only allow a registered user to see a site for which they are registered to – A registered person with any assigned user role can access only the site where they are registered.
- Only allow administrators of a site to view the site for which they are an admin – This setting lets only admins view sites and only the sites where they are admins. If they are n admin for one site, but a subscriber for another, they won’t have access to the other site where they are a regular user.
The Allow Override setting gives you the option to let admins choose different settings for their individual site if you choose the Yes radio button. Don’t worry, though – even if you choose to let admins override your settings, you still retain access to their sites and settings.
Finally, if you would like to update all sites in your network to include the changes you made – including future registered sites – check the box under the Update All Sites heading. If you only want new sites that are registered in the future to use these settings by default, then leave this box unchecked.
All the Multisite Privacy settings on this page control all sites in the network, except for the main site.
No matter what options you select, the main site won’t be affected. This ensures that you and other admin users won’t be locked out of your own site, users can register for access if you have enabled this feature and so you can provide support and help.
Editing the privacy settings for the main site is still possible by accessing your dashboard, then going to Settings > Reading, then scrolling down to Site Visibility. This is also the same place where admins can overwrite the settings for the sites where they are administrators if you have this option enabled.
Once you’re happy with the settings you have picked, click the Save Changes button at the bottom of the page. A page should appear next with a status message on it that looks similar to this:
“Applying to sites, please wait …
2 of 3 sites updated.”
If you have more or less than three sites in your network, it should be reflected in the message. Your changes should be applied, but may take a few minutes for larger networks so don’t sound the alarms if this process takes a few minutes.
Bug Testing Plugins and Tips
Now you’re ready to start tinkering away and testing for bugs. Generally, this means checking each element of a site or theme to make sure it works as intended, then reporting errors in detail anytime something isn’t working as it should.
The bug testing process includes but isn’t limited to:
- Checking elements such as clicking links to make sure they point to the intended site or page
- Filling out forms to make sure they work properly
- Making sure error messages don’t pop up when using the site
- That theme parts aren’t out of place
- Ensuring the site is fully responsive and not just mobile-friendly
- Making sure the site is fully accessible for the visually and hearing impaired
- Checking every nook and cranny of the site to make sure everything looks and performs the way you want
Responsiveness is an important part site development, especially when Google recently updated their algorithm to boost sites that are fully responsive and negatively impact those that fail the test. If you need tips on creating a fully responsive site, check out one of our other articles: Creating a Responsive WordPress Site Your Mobile Users Will Love.
Just as important is accessibility.
In terms of web design and development, this means making sure your site can be enjoyed by everyone.
People who have visual impairments often use keyboards to navigate sites and use devices called screen readers to read the text on the screen.
It seems like a simple request, but too many sites don’t fit the bill as I discovered when I did research on the dominating design trends of 2015.
Those who can identify as being hearing impaired may also require some site adjustments such as closed captions in videos, disabling the automatic playing of them along with sufficient volume control, just to name a few.
One of the strongest design trends and among the top offenders is sliders. In one of our posts, So Your Client Wants a Slider? Before You Cringe, Here’s What You Need to Know, I found out that most sliders are not fully accessible, and since only 1% of visitors actually click on a slide and your search engine rankings will plummet after adding one to your site, it seems fair to say that sliders should be a no-go on most – if not all – sites.
There are many elements to ponder over when it comes to accessibility and there’s more information on this topic including plugins and themes to help you out in one of our posts about accessibility.
The WordPress theme handbook also lays out everything you need to know in a clear and concise way to help you learn how to create fully accessible themes.
If you do find there are bugs on your site, it can be difficult to troubleshoot at times to find the initial cause. This is where turning on WordPress native debugging can be helpful.
When enabled, errors and warnings are displayed on the front end with the path to the problem file as well as the line of code where the problem lies.
Normally, this isn’t something you should use on a live site since it displays information about your files to the general public – including hackers – but Multisite Privacy can change that.
You can edit the site settings to only allow either those with a password you set, registered users, admins or super admins to view sites in your network. With this option saved, anyone who doesn’t have access is redirected to the login page and won’t see the error messages.
This does mean you still need to be cautious since turning on debugging means errors are displayed for your entire network, including your main site which means it may be necessary to password protect your main site as well as your entire network in the Multisite Privacy settings.
It’s not always ideal, but in a pinch, it does the job. For now, I’ll give you the abridged version of the setup process, but you can check out the full details in our post Debugging WordPress: How to Use WP_DEBUG.
To turn on the debugging feature, add this line in your wp-config.php file if you don’t already see it there:
WP_DEBUG code is present in the file, change
true if it’s not already set up that way. Be sure to also place this code above the
happy blogging line:
When you’re finished, remove that line, or switch it to
If you need to keep your main site as well as others public while debugging a specific site in the network, you can send the error messages to a private log instead. To do this, enter the following code into your wp-config.php file above the
happy blogging line:
There are a number of easy ways to test your site for bugs, responsiveness and accessibility if you don’t want to dig into code. Here is a list of plugins to help you test your site and iron out any issues.
These plugins are all maintained and updated regularly for best results. While not all the plugins on the list below were specifically made for Multisite, I still found they could be installed and used on individual sites in the network without issue.
Debug This is one of the most popular and best debugging plugins because it gives you access to debugging an entire Multisite network as a super admin. You have full control over the tests you run with a handy interface that’s accessed through the admin bar.
There’s also a ton of options to choose from to test for errors. For such a powerful plugin, it’s as easy to install as most other plugins which is a bonus.
If you’re happy with the idea of adding
WP_DEBUGor error logging to your wp-config.php file, but would rather not need to touch code, this plugin can do it for you.
It’s easy to install like most plugins and you can choose which debugging code you would like the plugin to configure for you. It does mean your wp-config.php file needs to be writable for this plugin to work.
For more information on how to update your file permissions, check out our post Understanding File Permissions and Using Them to Secure Your Site.
The Debug Bar is a hugely popular plugin with over 30,000 active installs and it tracks and shows you errors as they come up. You also have access to loads of helpful information about your installation such as how much memory is being used, the number of queries being run, how long the queries take and a lot more.
This plugin makes it easy to see exactly what state your site is in with all the numbers laid out in front of you. It also installs easily so you don’t need to worry about doing anything complicated just to set it up.
You can also bundle in the Debug Bar Slow Actions plugin to test the load times of your site quickly to help you see where improvements need to be made to decrease load times for your network.
While manually testing your site for accessibility is one of the best ways to ensure your site is fully accessible, Access Monitor machine tests your site for every possible angle where ever possible.
You can also schedule weekly scans to keep an eye on your site as you apply changes and fixes. A report is created listing all the issues this plugin catches, keeping sure that duplicate issues you already know about and manually fixed are filtered out.
It’s an easy plugin to install and use, but requires an API key that you can get for free on a trial. If you need more than 30 days and 500 tests, you can subscribe for a premium API on a monthly subscription.
With Google’s PageSpeed and shortcodes, you can test your site for speed, responsiveness and overall mobile-friendliness. It’s particularly helpful since you can visually see where your site stands in Google’s eyes in the generated report.
While you won’t be able to see your overall ranking, you do have access to detailed information to help you learn where you need to make improvements from incompatible plugins, poor page and image compression, to load times and proper element re-sizing, to name only a few.
It’s also easy to install and use. While the Mobile Friendly Audit Tool is free, it does require a Google Developer API key to run which may end up having costs associated with it depending on your usage.
While manual tests are often preferred among many developers for increased accuracy, it might not hurt to get a second option and double check your results.
Pushing Your Changes to Your Live Site
Once you’re done testing your site and you’re ready to apply your changes, you can easily make it happen in just a few clicks.
Navigate to Sites > All Sites in the super admin dashboard and hover over the name of the site you copied for testing. Click the Clone link that appears.
Instead of selecting the Create a new site radio button under the Destination section, choose Replace existing site.
Next, start typing the name of the original site where you want your changes applied into the search box below the radio button. Once the site name appears, select it from the list.
If you want to push your changes to the main site, leave this search box empty.
Under Options > Site Title, you can choose which title to push to the live site.
Clone blog title keeps the title for the site you selected to replace the existing one. The now available Keep the destination blog title option lets you choose to use the title of the original site that is being replaced. Finally, you can choose a new title with the last option.
Uncheck the box to let search engines read your site. If an additional section is displayed called Advanced Options, you can choose which custom tables you would like to include, just as you selected when you initially cloned the original site.
Once you’re done choosing your selections, click the Clone Site button at the bottom of the page. Don’t be alarmed if this process takes a few minutes if you are replacing the original destination with a large site.
You’re all done. Your changes should be pushed to the original site for your users to enjoy.
You have all the information you need to bundle together the Cloner and Multisite Privacy plugins, copy any site in your network to privately make changes and test for bugs and push your changes live to the original site. It’s an easy way to test your network for performance where you can get the best of both local and live site testing.
For more information on testing your site including helpful development tools, check out some of our other posts: How to Test WordPress On Tablets and Mobiles You Don’t Own, 8 WordPress Development Tools You Probably Aren’t Using and Powerful Must-Have Tools for Every WordPress Developer.
What does your current WordPress testing process and platform look like? Have you checked out Cloner and Multisite Privacy? Tell us your bug testing stories in the comments below.