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
I began running this website on Drupal 6 shortly after the official release. Before then, I periodically installed development versions of Drupal 6 on the production server during the weekends so others could judge the progress that was being made. During this period, I made the claim that I didn't really need any contributed modules to run my site on Drupal 6.
As I said last week, it's amazing how many people overlook the power of Drupal...even without its contributed modules. Yes, I'll be glad when the Views, Panels, and even the TinyMCE contributed modules are ready to use with Drupal 6. But I've always looked at contributed modules as modules of convenience and not necessity.
It could have been a bold statement that I made at the beginning of the year. Although Drupal 6 interest has finally overtaken Drupal 5, there still are a number of popular modules still under the designation of release candidate, beta, and even alpha. My site has shown that you don't have to always wait for contributed modules to upgrade a site to the latest version of Drupal. However, my statement was a lie. By the time Earl Miles released Views 2.0 Beta 1, I found I didn't want to live without my essential modules for very long.
The following are a list of contributed Drupal modules that I wouldn't want to do without here at CMSReport.com. I am neither the first word nor the last word of which modules you should be running for your Drupal site. In fact, by coincidence, Kathleen Murtagh has just written a similar list of contributed modules that should be considered. Some of the modules on my list are still going through their development phase and you'll have to assess the risk of using the modules on your own sites. Personally, I like to take the risk for my hobby sites such as these, but I am more cautious when using development code for sites managed at my day job. Whichever modules you choose, be sure to thank the developers that have made your site possible.
Contributed modules used at CMSReport.com
Sends e-mail to notify both registered and anonymous users about new comments on pages where they have commented. The goal is to drive one-time users that comment back to you site to convert them to real registered users. This conversion step is an essential one in building a blog comment community.
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.
Last night, I took the opportunity to spend some time with the Drupal community at a Twin-Cities Drupal Meetup. My trip to Minneapolis for the meetup was on the tail-end of a 1300 mile drive. Those miles covered a drive that looped me south to the state of Missouri and then eventually back north. My activities during the past week ranged from sleeping in the Missouri woods at an old scout cabin with outhouse included...to having conversations in Minnesota with some of Drupal's brightest and most active members.