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.
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:
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.
Since you are dealing with users (potentially) being able to manipulate your site (depends on your plugin), managing security and permissions is mission critical.
You need to set limits and run a cron job to clear out user submitted data every so often.
Only allow the users what they need to demo the plugin – remove the rest.
The Final Destination
Here’s what we will be creating – if you want to skip the tutorial, you can just download the plugin and use it for reference. 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. If you want to see how the plugin functions in real life, head over to the Soliloquy demo site and start having fun.
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.
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!
I live and breathe WordPress. I create products around WordPress (Soliloquy and OptinMonster), contribute to WordPress core and do lots of fun development around WordPress in general. You can find me on Twitter, Facebook and Google+.
I have created over 100 custom themes and plugins for clients of all shapes and sizes. I have also contributed to WordPress Core, spoken at several WordCamps and created some powerful WordPress products.
I create solutions that add value to your business.