Create a Live Demo of Your WordPress Plugin

Who doesn’t want to offer their users a live demo of their WordPress plugin?.. *crickets*

Exactly – if given the opportunity, I would estimate that 99.9% of plugin developers would like to offer their users an actual demo of the plugin before they used it. WordPress has adopted this mindset for themes with the new theme customizer tool, so it would make sense to allow our users to test out plugins in a similar (yet different) fashion.

I think the reason why a lot of plugins don’t have demo sites available is because the developers of the plugin don’t know how to do it.

But not knowing how to do it is no longer a good excuse because in this tutorial, I hope to provide plugin developers with a solid basis for creating a secure, permissions-safe and self sustaining demo site for their plugin(s).

And not only do I want to show you how to do it, I want to make sure you are _doing_it_right.

**Note: This is an advanced tutorial. I won’t explain every single detail of the plugin, so I expect you to study and learn from it.

Understanding the Foundation

It is important to understand the approach to creating a demo site before you actually begin building the code to make it happen. There are a few principles that you must live by when creating a live demo for your WordPress plugin:

  1. You must, must, must make your demo as a completely separate install of WordPress with a completely new database. Don’t try to mix things up – start from scratch. Whether or not you make the demo site as a subdomain, directory or completely different domain doesn’t matter as long as it is a separate install from your other endeavors.
  2. Since you are dealing with users (potentially) being able to manipulate your site (depends on your plugin), managing security and permissions is mission critical.
  3. You need to set limits and run a cron job to clear out user submitted data every so often.
  4. Only allow the users what they need to demo the plugin – remove the rest.

The Final Destination

Here’s what we will be creating. I’m using this code for my Soliloquy demo site. Keep in mind that your plugin is different from mine – the code will need to be modified to meet your plugin criteria. This tutorial is simply a primer and gives you a foundation and ideas on how to craft your own demo area for your plugin. 

It may look like a lot, but it is pretty simple once we break it down. Let’s get started.

Limiting The Plugin

It’s always best to start with the least possible permissions and add to them as needed. The subscriber role in WordPress is the absolute base level of user – it’s only permission is to read. This is ideal then because we can easily add new capabilities that allow the user to do particular things required of our plugin.

Assuming you have followed my instructions of creating a clean install on an empty database, you should only have two users in your demo area: the administrator and your demo user (a subscriber). Notice the method $this->is_demo_user() – this simply checks to see if the current user can manage options (an administrator only capability). This ensures that our demo plugin only affects our demo user. Nothing is loaded in the plugin unless the current user is actually our demo user.

From here, we store our role in a class property (remember, our demo user has the “subscriber” role) and then list out all the capabilities we want to user to have. In the case of Soliloquy, I need the demo user to have the following capabilities: edit_posts, edit_published_posts, delete_posts, delete_published_posts, publish_posts and upload_files. You can view a full list of capabilities in the Codex. Your plugin is different from mine, so obviously you will need to switch up what capabilities you want your demo user to have.

Once you have altered the capabilities to suit your needs, the next piece simply loops through the array of capabilities, and if the user doesn’t already have the capability, we add it.

Because I don’t want a million sliders being created on my demo site, I’ve limited it to 5 instances at any given time. I make sure we are in the demo area (which is just a check to make sure the user is viewing the “soliloquy” post type) and stick the check in the load-post-new.php hook. This ensures that my limit will never be exceeded.

Finally I add in some demo image sizes to play around with and then load the rest of the hooks and filters needed for the demo area. So far so good!

Security and Permissions

I’ll always err on the side of security. If users or potential customers are coming to view your demo, they do not yet know how your plugin functions. With this in mind, you want to make sure that you lock down your demo area so that only your plugin functionality is available to them and nothing else.

The method cheatin is my paranoia attempt to make sure that the user cannot access any page in the admin that I don’t explicitly give permission. It lists out all of the available pages in the WordPress admin and if the user tries to access one that isn’t a part of the demo area, it redirects them back to the Dashboard. Again, I’ll always err on the side of security when it comes to people actually interacting and manipulating your site.


The next few methods are mainly aesthetic polishing to the default behavior or functionality of WordPress for a subscriber. For those still following along, I’m simply going in order and explaining each method in the plugin.

First, I remove the ability for the demo user to fiddle with the screen options area. Unless your plugin utilizes this area, there is no sense in letting the user fiddle around with those options.

By default, a subscriber is directed to his/her profile page upon login. Again, unless your plugin utilizes the profile page, there is no need to let your demo user modify anything, so I simply redirect the user to the Dashboard upon successful login.

Next, I output a little message on the login screen and display the login credentials for the demo user.

I also want the Dashboard to be one column and free of widgets, so the dashboard method does just that.

Finally, I want to make sure that any unnecessary menu items and admin bar items are removed from the demo user’s view. The remove_menu_items method checks the global $menu array and unsets my specified items. The admin_bar method removes admin bar items that the demo user doesn’t need as well.

Again, I want to reiterate that your demo for your WordPress plugin is going to be different from mine. Alter and modify this plugin as necessary to suit your unique needs.

Polishing Off The Plugin

The last couple aesthetic methods are merely text and marketing for Soliloquy itself. I add in some text and content to the Dashboard area via jQuery and then modify the footer text as well.

Finally we instantiate the class to get our demo plugin rolling – and we are done!

Extra Touches and Final Thoughts

One final thing you should consider doing is creating a cron job on your server that will periodically wipe demo user generated data from the site. This keeps things fresh and makes sure you don’t have an incredible amount of junk (or possibly files) on your server.

Remember, this plugin is just to serve as a foundation and thought-provoking way to create a demo area for your users. I fully expect you to download, modify and customize the plugin to suit your needs.

I hope you have found this tutorial useful. Please let me know of your questions, thoughts, concerns and improvements so I can implement them into the tutorial and plugin!


I’ve been asked about how to handle the cron job in the comments. While I won’t go into detail on how to create a cron job on your server (there are plenty of good tutorials on the internet – just ask Google), I will share with you the script that I ping when my cron job fires every 12 hours. Click on the gist link below to view the script. Ideally you would study it, replace any all caps text with your appropriate settings and follow course.

Click Here to View My Cron Job Script for the Demo Site

In a nutshell, my file truncates two DB tables: wp_posts and wp_postmeta (remember to reference your DB prefixes if you have them set). I then create a “Home” page and set the option to make it static – this way my demo site always has a familiar page. Finally, I recursively look through my uploads folder and remove any files that the demo user has uploaded.

Hopefully the file is helpful and can get you started – let me know your questions in the comments!

Enjoy? See Inside my WordPress Toolbox

Over 20,000 people have purchased my WordPress products. Get absolutely FREE access to regular updates and my toolbox - a collection of WordPress-related products and resources that every WordPress professional should own.

  • chris

    I’m right there with you all the way up to letting people into the demo site to start playing around. Then what? Do you have any cron jobs or other routines set up to clear out the stuff/settings that people add to or change in the plugin?

    Edit: just saw that you did mention that at the end. Apparently tl;dr…any suggestions for how best to handle that? Cron job to do a database dump/restore or something (that seems extreme to me)?

    • griffinjt

      I’ve just updated the post with a gist of the script I use when my cron job runs every 12 hours. Obviously you will need to modify it to your particular server settings, but it should give you at least an idea on how to approach it.

      You could modify this script to do a database dump if you wanted. I simply truncate (empty) the tables and remove any user uploads that have incurred in the previous 12 hours.

      • chris

        Awesome. That takes care of the missing link. Thanks for that :)

        • griffinjt

          No problem – glad it pieced together the puzzle! :-)

          • sethshoultes

            Did you intend to leave your database password in the cron script?

          • griffinjt

            I did not mean to – thankfully no vital information sits in the DB. Exactly why this should always be on a separate install and DB. ;-) Updated and fixed – nice catch!

  • Jayant

    what plugin do you use for your affiliate management

  • joey

    share with you ..

  • SKT Themes

    Thomas you are awesome….just created a 1 click installer for our wordpress themes using this…

  • Pingback: How to Create a Demo / Test Drive Site for your Theme or Plugin : WPMayor()

  • Pingback: Create a Live Demo of Your WordPress Plugin | Multipop()

  • Nabtron

    why not setup a multisite?

    I’m using multisite for my demos (for themes basically) at

  • Xyi

    activated plugin – not accessing admin panel ( demo, demo )

  • i4x

    This tutorial is lacking, for instance I can’t find on what line the whole function executes, as I haven’t got to grasp OOP coding till now (others didn’t too), in my case my plugin uses manage_options although it doesn’t use edit_posts, so I want to check if !current_user_can(edit_posts) and on that alone, the whole class(Plugin) would execute and I’d remove some of what I don’t need, or even only use the dashboard editing function. All-in-all thanks for this although I’m still searching around to find something simpler to work in my case.

  • Astried Silvanie

    Thankkssss !!! :) It help us

  • Ashley Evans

    Thanks so much for this! I have a demo site for my plugin now, but it’s rubbish because I don’t do any kind of reset. So people come in and make it look like crap, haha.

    I’m definitely going to give this a try when I redo my site. Thanks!