In the Drupal project page form there is a Project Resources section which includes the ability to add links to, you guessed it, project resources, things like Homepage, Documentation, Screenshots, and a Demo Site.
I only have a few modules that I have contributed to Drupal, and even the ones that I have contributed do not get much foot traffic. Still, I strive to be a good module contributor and maintainer, by doing things like writing good documenting in and outside the code. I also like to have links for all the Project Resources. This is not always possible. Often people (myself included) just link the Documentation to the current README.txt file in the CVS repository. I have started just linking the Changelog category to the CVS messages for the module.
I have always wanted to be able to have an actual place to demo my modules without linking to this specific site. But I never wanted to spend the time both initially and ongoing to create a demo site for each module. It's a fair amount of work, and there is always the issue of security, and concerns of users creating offensive content. So, I never did... until now!
So, why should I even bother creating a demo site when someone can just download the module and try it out? Well, here a few of the many reasons why a demo site is a great idea for modules:
The Demo Module has been around for quite some time. It's a fairly straightforward module that allows you to taken a snapshot of your site and reset it back to that point. A snapshot is basically a database dump. So, a site can reset itself as often as you want.
So, I put it all together in a few hours and created the Zzolo Sandbox. It resets every hour. It's main goal is demo my modules (I still have some more to add).
It's simple:
My modules are pretty simple. Once you get into more levels of depth, you may have to consider how you want visitors to interact with your demo, but since it resets itself, there is not too much to worry about.
In this process, I had to think about how my modules would react in this environment. Most importantly, I had to consider my module's permissions and cron. But there are many things to learn from this environment for a module, including the following:
One thing that was bugging me when I was setting this up was that the user had little idea to when the site was going to reset (or that it was a demo site), meaning that they could be in the middle of something and have the site change drastically. So I made a simple block with a timer on it.
This is using the jCountr plugin to create a countdown to the next reset. I had set up the demo to reset every hour and cron to run every 43 minutes on the hour and this is hard-coded here. This is not necessarily well-written Drupal code, but it is secure and does the job. Here is the Drupal block hook:
Here is the Javascript:
CAPTCHA
I was just thinking about spam on the sandbox site. I have installed the CAPTCHA and reCAPTCHA modules. It then hit me that the administrative pages did not have CAPTCHA added to them. I was then like "That's ok, CAPTCHA allows you to add itself to any form given the ID." Well, looking into it, this is not true. CAPTCHA doesn't think that I should be able to allow my administrative forms to have it. I briefly looked into the issue queue and did not see a similar issue. I will look into this more, and cross my fingers in the mean time.
Sweet Drupal Community
I looked into the code of CAPTCHA, and it basically restricts its actions to pages that are not admin/*. It was a simple fix to remove the conditional statement, but I started this issue: #445026, and soxofaan made a quick patch!
I did find out that the reCAPTCHA modules does not work with the current CAPTCHA 6.x-2.0beta. Which is unfortunate because I like how reCAPTCHA works.