During the past couple years I have recommended to people that they host their Drupal sites on a virtual private server (VPS) instead of a shared hosting plan. While a large number of people do not have problems running Drupal under shared hosting plans, I have always felt that there are less headaches with using a VPS to host your sites. For example, with a VPS I don't have to worry whether the shared hosting plan gives me the necessary MySQL privileges needed by Drupal (especially CREATE TEMPORARY TABLES and LOCK TABLES). From time to time, you also hear from people with "Drupal friendly" shared hosting plans eventually find that their hosting company isn't so friendly toward their Drupal site. Planet Drupal contributor, Clancy Ratliff, is one of the most recent examples for having a host provider not really happy she is using Drupal. So I often ask myself, is shared hosting for Drupal really worth the trouble?
I don't know if shared hosting is worth the trouble but a chain of events have brought me to giving shared hosting another chance for my Drupal sites. Last month, I pushed my VPS so close to the bleeding edge that it became unstable. While I was able to get my sites back online, the downtime clearly told me it was time to move my sites to a new server. While most visitors observed a performance improvement for my Drupal sites since the server migration, it's only now that I'm letting the cat out of the bag. For the past week, CMSReport.com has been under a shared hosting plan and not a VPS. I'm currently running my site using a budget shared hosting plan through my reseller site which is comparable to the hosting plans offered by GoDaddy.
I don't know how long I'll keep my site on a shared hosting plan but I am currently enjoying a break from the work, worry, and experimentation that comes with administration of a VPS. While I may go back to a VPS, I thought it would benefit some newbies and other Drupal users my experiences and thoughts on migrating my sites from a VPS back to a shared hosting plan.
Budget hosting revisited
Many of the budget shared hosting providers have improved their features and services over the past year or two. The shared hosting companies are finally understanding that the future is in Web 2.0 applications and not static pages. For example, many of the host providers now give you the choice of running your site on PHP4 or PHP5 as well as MySQL 4 or MySQL 5. In the past year, my shared hosting plan now allows for LOCK TABLES in MySQL databases (but has yet to grant account holders rights to CREATE TEMPORARY TABLE).
Also, there has been an explosion of shared hosting plans which allow you to add multiple domains (websites) to your single shared hosting plan. In other words, budget shared hosting plans are giving you a little more control over the hosting features you have available for your site. However, are all these added features enough to run Drupal? I'm working on finding out that answer.
Drupal search, temporary tables, and alternatives
One of the biggest drawbacks for me with my shared hosting plan is the inability to CREATE TEMPORARY TABLES. Without the ability to be able to create temporary tables in the database, the core Drupal Search module does not work. From time to time, there is discussion of providing a search module without temporary tables but many of the core developers believe it would come at a cost to performance and are not eager to make the change.
Luckily, there are alternatives to the core Drupal search module. Some have suggested hacking the core but luckily you don't have to go that extreme as there are other alternatives. One alternative I'm currently using is the the SQL Search (aka Trip Search) module. While the SQL Search module is not as robust as the core search module...it works and meets my needs.
Importing the database via phpMyAdmin
Let's just say that migrating a site from cPanel or Plesk to a unique control panel ran by the shared hosting company isn't painless. Luckily many shared hosting companies now offer phpMyAdmin as an alternative to their own tools for managing your database. However, not all is yet perfect in the land of databases administration.
My host provider decided to limit the size of the SQL file you can import to 2 MB which is a problem when you have a 20 MB SQL file. Since many of the hosting companies use remote databases, it's likely you won't be able to change that limit they have set for you. To get around the 2 MB import limit I had to do two basic actions:
- Empty data from tables that are only being used to store "temporary" content. For example, I really didn't have the need to carry over the content of the accesslog table or the four cache tables in my database.
- Cut and paste the downloaded SQL flat file (now down to 12 MB in size) into smaller 2 MB files. I had to import six SQL files into the database when it was all said and done. Yet, it' was a pain in the rear-end to do but it had had to be done.
Multisite Drupal configuration
First, what is multisite configuration? From the Drupal 5 install instructions:
A single Drupal installation can host several Drupal-powered sites, each with its own individual configuration.
Additional site configurations are created in subdirectories within the 'sites' directory. Each subdirectory must have a 'settings.php' file which specifies the configuration settings. The easiest way to create additional sites is to copy the 'default' directory and modify the 'settings.php' file as appropriate. The new directory name is constructed from the site's URL. The configuration for www.example.com could be in 'sites/example.com/settings.php' (note that 'www.' should be omitted if users can access your site at http://example.com/).
In other words, if you have five sites and they all use the same contributed module then with multisite configuration you only have to upload the new/updated module to your server once and not five times. The Drupal handbook contains additional useful information about multisite configuration including how your directory structure would look like with the new configuration.
All this time, I never took advantage of multisite configuration so I decided to have fun with it this time around via the shared hosting account.. I've ran into a few problems such as how to not have the Drupal sites share the same files or images directory but this appears to be a problem not unique to my shared hosting nor necessarily a Drupal problem. Overall, I'm quite satisfied with how the multisite configuration is working my for site. I really can't believe I'm doing all this at about only one-fourth the cost of my VPS.
Concluding the first week of shared hosting
To be honest, hosting my Drupal account on a cheap shared hosting plan has gone better then expected. It still is too early to tell whether my sites will continue to function well without the benefits of a virtual or dedicated server. I also wouldn't be surprised if one day I get a call from the host provider that my Drupal sites are taxing their system.
If the doom and gloom do become a reality, I can easily migrate my sites back to a VPS. In the meantime, I think it's important to see how Drupal does work for those who host their sites on budget shared hosting plans. After all, if you're a newbie to CMS and testing Drupal for the first time you are likely going to install it via a shared hosting account before you consider forking the money over to lease some time on a VPS or dedicated server. I'm enjoying this experience and hope to not be disappointed in the near future with running Drupal on a budget host. Stay tuned.