We lasted nine months. That's right, for nine months we hosted our Drupal site with a shared hosting account. Last January, I knew we were taking a gamble but the monthly cost savings for hosting the site was just too tempting. In this end though, CMS Report was too busy and exceeded the shared hosting provider's CPU usage policy.
When I recommend to someone that they should use Drupal for a project it is not uncommon for them to question my wisdom on the subject. Those new to Drupal are often shocked by Drupal's initial learning curve, no rich text editor in the core, and a user interface with a longer workflow than it really should be. As powerful and functional as Drupal can be it historically has had usability issues.
Acquia used the first day of DrupalCon DC as well as their corporate site to announce the availability of their new service via a public beta program, Acquia Search. Acquia Search is "based on the powerful Lucene and Solr technologies from the Apache project" and "creates a rich index of your site content". While Apache Lucene and Apache Solr are "free" and open source, the implementation and maintenance of these products can be rather daunting. Acquia wishes to solve this complexity problem by offering Solr search as a service in their Acquia Network.
Before the beta was available to the public, CMSReport.com was invited by Jacob Singh to join the private beta program to test and review Acquia Search. I have only been using Acquia Search for a week so I still have some learning to do in order to take full advantage of the advanced configuration options in Apache Solr. Although I'm new to Apache Solr, I have to say that from a website owner's perspective the implementation of Apache Search was extremely easy. After I signed up for the service on the network, implementing Acquia Search within the Acquia Drupal CMS was just a matter of activating the appropriate modules and waiting for my content to be indexed by the server. Acquia Search works straight "out of the box" and I couldn't have asked for anything simpler.
I have never had good luck hosting my Drupal sites on shared hosting plans. My last venture into budget hosting was a disaster with the hosting company locking me out of my own account due to too many requests to the remote database. The truth is that I've only been happy with running my personal Drupal sites on virtual private servers (VPS). However, I'm having a difficult time justifying my yearly costs of using a VPS to host my sites.
Last year I was one of the beta testers for Acquia's Drupal distribution and the Acquia Network. I was evaluating Acquia's products and services for a potential intranet project at work. For this particular project, unfortunately, it looks as if Acquia or Drupal wasn't the right solution. Our regional folks wanted a solution similar to Microsoft's Sharepoint that is more integrated with Microsoft Office and heavily featured in document management. That's alright though because there are a number of smaller intranet projects at work where Drupal is the perfect solution and a lot of
The April issue of Adobe Edge contains the article, Review of open source content management systems. The article provides an overview of what the author describes as "five of the top open source software (OSS) solutions". The five open source CMS included in the author's list are CMS Made Simple, Drupal, Joomla!, WordPress, and XOOPS. After reading the article, I found myself wondering how we "reviewers" can actually improve our reviews of open source CMS. More importantly, I've come to the realization that I can no longer claim to be non-biased in which CMS I believe is the best out there.
The author does a fine job in the article describing the similarities and differences between the CMS being reviewed. However, one of the issues I have in this article and many others I've read that review CMS is the big jumps in the conclusion:
Drupal, Joomla!, and XOOPS are best for building an e-commerce site because all three offer:
- Inventory management
- Support for third-party payment processing mechanisms (such as PayPal)
- Modules for shipping and sales tax calculators
- Shopping cart functionality
While it is true that Drupal, Joomla! and XOOPS can do e-commerce, none of these CMS can do that straight out of the box. I can just imagine a shop owner or design company trying Drupal, Joomla!, or XOOPS for the very first time and wondering, "how the heck do I get a shopping-cart into the CMS?". While the author does hint in the article that third-party modules are needed to make the e-commerce work, I think the author would have been better off better explaining that "some work is required" to get those features into the CMS.
Linux.com is featuring a story by Susan Linton titled "Drupal 6 keeps getting better". The author claims she has been using Drupal since version 3.1 and seems to know Drupal well enough to write a decent article. In short, she does a fairly nice job of summarizing the features introduced in Drupal 6. However, she ends the article with a rather strange conclusion.
My primary complaint with Drupal is still not addressed in this release. I believe having advertising capabilities is almost a necessity in any content management solution. Instead, Drupal leaves users to their own skills or to use a contributed module. The lack of native advertising support remains a major drawback.
I rarely have seen such request for an "advertisement feature" in the core of any CMS I've reviewed. Yes, some CMS do have an advertisement feature but in most cases the capabilities of such built-in features are usually limited. Either way, I just can't imagine with the latest drive to strip the less needed modules in Drupal 7 and beyond, that the Drupal developers would go for an ad module in the core.
You and I have a dirty little secret. Many of the Web applications that we call content management systems (Web CMS) are not really content management systems. Huh? A lot of this confusion stems from the difficulty most of us have in answering what should be a simple question, what is a content management system? Scott Abel, The Content Wranger, has noted in previous comments that one of the problems in discussions about content management is that we really lack a common definition of CMS.
A couple months ago, I experienced a number of errors at my Drupal site that all pointed to a corrupted database. I believe the problem likely was the caused by a sloppy export/import I performed with the MySQL database while moving the site to a new server.
While my particular database problem was an easy fix, if you really don't know much about databases you may find that you really need some guidance on how to solve problems like these. This article is the process I went through to correct this particular MySQL database problem in Drupal 5 and some general database rules that show why this problem occurred in the first place.
If you are reading this post, then congratulations...you are now seeing CMS Report on its new server (a Virtual Private/Dedicated Server). As I tweak the VPS in the following weeks, I may fall back on the old server from time to time but for the most part, I'm home. Today officially ends my grand-experiment of running a moderately busy Drupal site on the cheap.