Posted on

Why Your Demo Site Sucks, and What to Do About It

Over the past few months, I’ve been running into a problem with the WooCommerce UPS Toolbox. Because it’s such a specialized product, many prospective buyers naturally want to try it out for themselves to make sure it’s a good fit for their needs. While I’ve had a demo site up for all of that time, it’s a bit complicated.

Because it requires UPS account credentials, and I don’t really want to broadcast my own account info, and I definitely don’t want to expose a potential buyer’s account info, so that means I’ve been wiping the previous user’s account info and creating a new user each time someone asks for a demo.

Additionally, I’m sure it’s a bit of a pain to have to send someone a message requesting a demo, so that probably means for every person that contacts me asking for a demo, there are probably 5-10 others that want a demo, but don’t want to go through the trouble of sending a message.

The Spark

A few weeks back, it occurred to me that I needed to find a better way to set up a demo site.

For starters, the user needed to be automatically logged in after clicking the button/link to view the demo.

Next, I needed to be able to restrict access for the demo user so it had the access it needed, but no more. In addition to  preventing unwanted changes to the site, this would have the added benefit of removing distractions to anyone using the demo.

Third, I needed to be able to dynamically divert new users to different sites so multiple users wouldn’t get logged into the same site.

User Experience – Who is Doing it Right

These requirements are primarily just for the sake of managing the demo site(s) and doesn’t take much into account the actual user experience (as well as the goal of funneling demos into sales). One good example of who is doing this part right is Envato – both ThemeForest and CodeCanyon have a “Live Preview button for every product, which opens a new window and contains the actual demo site within an iframe and contains a “Buy Item” button which returns you to the product page.

While I think that adding the item to the cart would be a better option here, unless you’re selling a simple item (with no variations) this could overcomplicate the UI a bit.

Demo Bar

The Solution

I had been considering building a solution that handles all this, but frankly, this would be a huge undertaking. There are lots of moving pieces, and a lot of things to consider when building something like this – especially if you intend to share it with the world. I was glad when I stumbled across NinjaDemo a week ago.

NinjaDemo is a fairly new product, so it doesn’t open the demo in a new window or display a “buy item” button in the header(yet), but what it does do is very elegantly allow you to set up demo sites for any number of products, and have each of those be replicated numerous times without needing to clean anything up. After a preset amount of time, each replicated demo site is simply deleted, and new ones are always copied from your the original (which can only be altered by you).

You also have a fairly finely grained control of access for the users that will be accessing this site, so besides choosing what user will be used to login (so you can create a user with a basic role) you can also restrict all the admin menus that they will have access to.

Setup Challenges

As with any amazing product, there are some difficulties with setting it up. The main requirement is that your main site – the one you’re linking the demos from needs to be multisite enabled – and not just any kind, but it absolutely has to be a subdirectory multisite.

The problem with that is that if your site is more than a month or so old, WordPress won’t let you choose subdirectory

“You cannot choose Sub-directory Install (for a path-based network) if your existing WordPress installation has been set up for more than a month, due to issues with existing permalinks. (This problem will be fixed in a future version.)” codex link

There is a workaround for this, though. There’s a code snippet that needs to go somewhere. I’ve heard people say to put it in your active theme’s functions.php, but that just seems like a bad idea for a number of reasons. I think a better solution is to put it in your mu-plugins directory.

mu-plugins are very different from your typical plugins. They don’t require the standard plugin header that normal plugins have and they don’t need to be enabled, as the “mu” part stands for “must use” as in “always on”. So, basically, all you need to do is add a php file to the /wp-content/mu-plugins folder (create the folder if it doesn’t exist) and add this to the file:


<?php add_filter( ‘allow_subdirectory_install’,
create_function( ”, ‘return true;’ )
); ?>


From there, you’ll be able to enable subdirectory multisite, and it’s pretty much cake from there on out. Set up a new subsite for each demo you want to be available, set the options for each, and then use the shortcode where you want the buttons to be (make sure to set the site_id for the respective demo site).