Tuesday, February 2, 2010

10 Ways to Make Drupal Die

I can't take credit for these, having overheard them at a Drupal Meetup in the area. While cleaning up my desktop, I found them in a text file of notes (I didn't have wi-fi access at the time.) These were classified as "Evil".
  1. Modularize the Synchronization of the Site with other Databases
    If you need to implement a synchronization process between the Drupal database and another distinctive codebase (CiviCRM?), don't do it as a module. In general, a module is a chunk of functionality, but it is invoked when a node is loaded that contains content of a type processed by the module. That just isn't the right flow for a cross-cutting operation like a site synchronization.
  2. Install untested modules
    How well did the developer test the module you're about to install? Try reading the reviews. If there aren't any, what makes you think it isn't a completely bogus piece of malware? That's unlikely with the community involvement Drupal has, but you've got to look at a lot of these modules as experimental until they've been well vetted.
  3. Hack the core
    Drupal allows extension in a separate set of site folders. Use them. Don't mangle the baseline of files in the standard folders. Changing the core files assures that you either (a) will neglect security updates or (b) will lose your extensions or (c) will crash your site with an "easy fix". Or all three. Any way, it is bad.
  4. Neglect a good update and security patching process
    Even if you don't run a site as popular as Slashdot, you cannot rely upon anonymity to protect your site against crackers. Drupal actually reminds you that new patches are available to apply to the core. But the correct process is to (a)Back Up (b) back out all of your add-on modules (c) Apply Patches (d) Re-install your add-on modules and (e) Back Up again. It can be really annoying to back out and re-enable all those modules, but understand that if you don't do things in the right order, you could potentially screw things up royally.
  5. Depend upon a module for a core feature, which you are not ready to support.
    Community modules may be free but can you get support? Think about what it means when even the original developer won't touch the code. When Drupal needs to be updated for a security patch, what do you do if your module is found to be incompatible?
  6. Bloat your system with lots of modules
    Under Drupal 6.x, it is often hard to deploy a meaningful feature without loading module upon module, and it can snowball. You can end up with so many modules that the number of database queries explodes, and responsiveness dies. If you are over a couple of dozen modules, you're in the kill zone. (A suggestion was to use the Watchdog module to profile queries.)
  7. Pull syndicated content into your database with custom modules.
    Consider a module that reads twitter feeds or scrapes atom/rdf published HTML newsletters. If the content and PHP code is not well designed and rigorously tested, such a module could do a lot of damage to the Drupal database, and kill your site.
  8. Allow a print-oriented firm to develop the site
    This is a somewhat biased viewpoint. Ford Motor Company uses sculptors to create conceptual designs for autos, but it takes a team of real engineer, not sculptors and marketing types, to do the engine and drive train work. To be capable of safe deployment of a Drupal site a company needs not only artists and marketing gurus, but skilled engineers. A marketing company without on-staff expertise may even be able to hide bad practices out of sheer luck, but ethical deployment of a Web CMS like Drupal requires a certain level of commitment to good engineering practices. What is the process for unit testing and performance profiling, revision/build management, source-code control, and digital asset management? What is their process for evaluation and updates when security patches are released? Or is the method just a "catch and release", with the client left holding a Drupal bag they're not prepared to maintain?
  9. Switch versions of MySQL and PHP without checking compatibility
    In particular it was observed that PHP 5.3 and Drupal 6 were incompatible. In engineering terms, we refer to this as "platform provisioning", the whole point of which is to avoid conflicts between components, and yep, it requires more testing. Good practitioners will have separate evaluation sites, and will use automation to hammer on the facility and sniff logs for problems.
  10. Use Views for search.
    This was out of the mouths of some of the more experienced Drupalers, who said that overextending the Views can actually trash the entire system. In response to a users' 49 word search, Views attempted tried a 49 way SQL "join". Trust me, that's a bad thing. They initially tried to limit the number of search terms, but ended up using a custom hook. Other suggestions were to use an external system like Apache Solr, or the Faceted Search module if the site is smaller than 10k nodes or so. Just don't use Views to do search.

No comments: