$100 Drupal Site Series: Part 4 - Platforms
So far in this series we have covered a potential target market and business plan, resources and infrastructure and the tools required to deliver Drupal sites with a sale price of $100 per site. In this post I’ll be covering some of the considerations when building Drupal platforms or distributions.
The sites which customers deploy will need to be based on a custom Drupal distribution or “distro”. The distro should be modular and primarily driven by Features.
Customers shouldn’t have to know anything about administering Drupal when they first buy their site. A customer should be able to turn functionality on and off as they want, through a simple user interface.
Features
The platform should contain a good collection of Features. The following list is an example of what you might offer customers:
- Contact Form
- Image Gallery
- Products
- Services
- “Static” Pages
- Blog
- News
- Mailing Lists
- Social Network Integration
- Office / Store Locations
- Staff Profiles
When developing your list of things to include in the site, think in terms of functionality a small business would want, not what modules you should be using. The list of modules should be derived from the functionality, not the other way around.
As the features included in the platform will be modular and generically useful, you should consider releasing them publicly, via your own features server or drupal.org as full modules.
On top of the features listed above you will probably need to include some custom glue code to enhance the user experience. In my first post in this series I discussed the target audience not having high level computer skills, so the user interface should take this into account. Some of the language might need to be changed or form options modified to use sane defaults and some might even be hidden from the user.
Security
As each server may have hundreds or even thousands of sites running on it, security will be an important consideration. Like with all servers you should ensure it is properly locked down and only running the services you need. Apache should be configured to block access to most things except index.php and relevant client side files (images, css, js) and the files directory. At the Drupal level you should make sure that things like the PHP module aren’t enabled and secure coding practices are adhered to. The user account given to your customer shouldn’t be user 1, they should be user 2, with restricted permissions that only gives them access to what they need.
I strongly recommend that you read Cracking Drupal by Greg Knaddison.
Sales and Support
In order to attract customers you will need a site to promote the service and allow customers to sign up and hand over their credit card details. Drupal now offers 3 ecommerce projects, Drupal e-Commerce, Drupal Commerce and ubercart. You should investigate which of these best suits your needs. The sales system will need some custom code to hook into Aegir, which will be managing the actual site deployments. The sales and support platform/s should be managed in a similar manner to the customer sites.
Once you have paying customers, you will also need to provide them with some resources such as detailed documentation, video walk throughs, forums and possibly a ticketing system. This site can either be part of the sales site or a separate site. In the next instalment I’ll cover support in more detail.
Deploying Platforms
We need to keep the whole process very automated, CPU cycles are a lot cheaper than workers. Building and deploying platforms should involve a few clicks or tweaking a configuration file. For example platforms could be built as Debian (or Ubuntu) packages (aka debs) using an automated build process that runs a test suite against the code base before building a deb. The debs could then be deployed using puppet and a post installation script can notify Aegir that it has been installed successfully. The whole process could involve very little human interaction. Migrating client sites to upgraded platforms could also be automated using a simple script which adds a migrate task for each site.
What’s Next?
Now that we have the service almost ready to go, we should look into how we are going to get customers to part with their cash and how we will support them once they have paid.