Planet Drupal

Last week was a very frustrating time for me. For whatever reason, an unusually number of botnets decided to zero in on my Drupal site and created what I call an unintentional  Denial of Service attack (DOS). The attack was actually from spambots looking looking for script vulnerabilities found mainly in older versions of e107 and WordPress. Since the target of these spambots were non-Drupal pages, my Drupal site responded by delivering an unusually large number of "page not found" and "access denied" error pages. Eventually, these requests from a multitude of IPs were too many for my server to handle and for all intents and purposes the botnet attack caused a distributed denial of service that prevented me and my users from accessing the site.

These type of attacks on Drupal sites and numerous other content management systems are nothing new. However, my search at Drupal.org as well as Google didn't really find a solution that completely addressed my problem. Trying to prevent a DDoS attack isn't easy to begin with and at first the answers alluded me.

I originally looked at Drupal for the solution to my problems. While I've used Mollom for months, Mollom is designed to fight off comment spam while the bots attacking my sight were looking for script vulnerabilities that didn't exist. So with Mollom being the wrong tool to fight off this kind of attack, I decided to take a look at the Drupal contributed model Bad Behavior. Bad Behavior is a set of PHP scripts which prevents spambots from accessing your site by analyzing their actual HTTP requests and comparing them to profiles from known spambots then blocks such access and logs their attempts. I actually installed an "unofficial" version of the Bad Behavior module which packages the Bad Behavior 2.1 scripts and utilizes services from Project Honey Pot.

As I had already suspected, looking for Drupal to solve this botnet attack wasn't the answer. Pretty much all Bad Behavior did for me was to take the time Drupal was spending delivering "page not found" error pages and use it to deliver "access denied" error pages. My Drupal site is likely safer with the Bad Behavior module installed, but it was the wrong tool to help me reduce the botnets from overtaxing Drupal running on my server. Ideally, you would like to prevent the attacks ever reaching your server by taking a look at such things as the firewall, router, and switches. However, since I didn't have access to the hardware, I decided it was time to look at my Apache configuration.

While I was at DrupalCon last week, Chris Pliakas sent a tweet out that he used screenshots from CMS Report in his Apache Lucene presentation. I'm always flattered when this site gets noticed for something we're apparently doing right. In this particular case, we're using the contributed Drupal module Search Lucene API for our search engine as well as for faceted search and content recommendations (recommended links).

If you had talked to me a few years ago, I would have told you that the Search module that comes with the Drupal CMS is all a site like mine needs. After I became a beta tester for the Acquia Network along with their implementation of Apache Solr called Acquia Search, my opinion quickly changed. I'm now convinced that an enterprise quality search engine is truly something that can make or break your website. If you're a smaller Drupal site that feels like Solr or Acquia Search is overkill or not in your cost range, Search Lucene API may be the answer you've been looking for all this time.

The actual name of Chris' DrupalCon presentation is: "Build a Powerful Site Search with the User-Friendly, Easy-to-Install Search Lucene API Module Suite". The video of his presentation can be viewed at Archive.org and has been embedded above. Screenshots from CMSReport.com can be seen in the time frame from 19 minutes to 21 minutes.

In the world of open source CMS there is no comparison more attention getting than an article comparing Drupal and Joomla!. Probably, the granddaddy Drupal vs Joomla! comparisons of them all was posted over three years ago by the Joomla SEO company, Alledia. I extended the discussion Alledia started with my own comparison between Drupal and Joomla. My article evidently struck a chord in late 2006 and currently is approaching near 200,000 reads.

Good comparisons between Drupal and Joomla! are popular because quality comparisons between the two applications are rare. It's very difficult to have passion for one CMS, be well informed on both CMS, and in the end be non-bias in your comparison. In the three years since I wrote my article, I've only come across three additional comparisons between Drupal and Joomla! that I thought worthy to bookmark.

I haven't updated my own article comparing Drupal and Joomla because I have developed a bias opinion over the years that I can't overcome. Both are good applications in their own right, but in the end I almost always recommend Drupal over Joomla!. That's why I'm glad to see Alledia update their own comparison between these popular CMS with "Joomla and Drupal - Which One is Right for You? Version 2".

Passwords, user accounts, email verification. I have never liked requiring my website's visitors to register before they can leave a comment. There is a large segment of people that like to submit quality comments online, but they don't want to be required to leave their personal information there. So from the beginning, I have always allowed anonymous commenting by unregistered visitors and for the most part, they quality of the comments haven't suffered. However, allowing for anonymous comments also invited my site into a war against comment spam. My latest weapon to do the fighting for me in this war is Mollom.

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 pr

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.