A couple days ago, when building a quick site with limited functionality (basically a pretty front end to a database website), I ran into a hiccup with my custom module/theme for the site, which caused me to scratch my head for a few minutes.

In my custom module (called 'idcards'), I added a stylesheet for a couple forms on the site using the drupal_add_css() function:

/**
 * Implementation of drupal_add_css()
 */
drupal_add_css(drupal_get_path('module', 'idcards') .'/idcards.css');

Later on in the development, I added a custom theme (based off a Zen subtheme I use for many smaller sites), and in that custom theme's .info file, I added a stylesheet named idcards.css.

When I cleared all the caches, I noticed the custom form styling (added by the module's idcards.css file) was missing, and on further investigation, I found that the module's idcards.css file was not being added to the pages!

Luckily for me, this is a small site, so I pretty quickly intuited that it was probably a namespace collision of some sort, and I renamed the module's file to idcards-forms.css. This fixed the issue for me, and now both stylesheets are happily living together. But just throught I'd share this tip in case anyone else encounters this problem: Make sure each one of your site's stylesheets (whether added by a module, your template.php file, or your theme's .info file) has a distinct name.

Part 1 of a series: Building out a full Drupal site in a weekend.

Before you start building your website, you need to get all the parts of the site together, and have a good plan for what you'll need and how you'll do it. For many organizations, this can be a huge hassle, as you'll have to go through planning meetings, make diagrams, have all kinds of changes, and end up pre-stressed... and that's before you start working on putting the site together!

Luckily, for this website, the requirements are pretty simple: I can do whatever I want. But I can't get started from that point, so I put a few requirements down on paper, then grabbed everything I needed.

This weekend I am going to attend the Catholic New Media Celebration. I'll be on two plane flights, I'll be sitting at an airport for a few hours before each flight, and I'll be at a convention all day Saturday. I'm hoping to build out a new site idea I've had lurking in the back of my head for some time: Open Source Catholic.

In the past 45 minutes, I've been jumping around Drupal.org downloading all the different modules and tutorials I think I'll need. I've also saved some of my previous work on other Drupal sites in case I need to refer to a code snippet along the way while I don't have Internet access. I'm going to call it a night for now (I need to pack!), but tomorrow, beginning at the airport, I'm going to start working on the site.

Right now, there's a splash page. No theme, no Drupal installation—nothing more than a simple welcome message. By Monday, I'm hoping to have a Drupal site with a new theme (which I hope to contribute back to d.o as a zen subtheme) and all the community features I can possibly cram into it. One man, three days; almost no free time to work with. Think it can be done? I think so! Follow me as I begin this fun and crazy journey!

[UPDATES:]

1. Part 1: Putting the Puzzle Together
2. Part 2: Theme Development
3. Part 3: Going Live...
4. Part 4: [Final] Releasing a Theme on d.o!

In what will be the first of, I hope, many case studies, I review the process of redesigning the Saint Louis Review website, from the ground up.

The Saint Louis Review is a local Catholic diocesan newspaper serving the nearly 500,000 member Archdiocese of Saint Louis. The newspaper has had a website since the late 90s, which was ported to a custom-designed CMS in 2001. The PHP/MySQL-based site ran quite well throughout the first decade of this millennium, but was in need of either a serious overhaul or a redesign, to go along with the paper's new tabloid layout in April 2009.

The decision was made in 2007 to port the website to Joomla, but after a few months, a new editor, and more work, it was determined that, due to its extensibility, flexible out-of-the-box permissions, and standards/SEO-compliant codebase, Drupal would be a better fit for the site. Work was begun in January of 2009 to transfer the custom CMS' articles database (over 17,000 articles) to a Drupal site, create a new template based off the colors and design of the new tabloid-format paper, and integrate an easier-to-manage ad system and back-end.

There are only two or three Drupal modules that I have installed on every single Drupal site I set up. At the top of this short list is Global Redirect. There are many reasons for its existence, not the least of which is Search Engine Optimization. Global Redirect does such niceties as remove slashes from the end of URLs and makes sure the home page of the site is the standard home page, and not an alias to it (like /front, or /home-page).

Basically, the module is an "SEO-in-a-box" module; sure there are other things you should do to get your Drupal site more optimized, but this module is like the icing on the cake for Drupal. It makes sure that all links to the site will direct to one, and only one link. That way, people copying out a link to a certain page on your site always get the same link, thus boosting your pagerank.

But this module earns kudos from me for more than that reason alone; it goes one further and does something that almost no other Drupal modules do: makes life simple. Download the module, copy it to your server, enable it, and you're done. The default settings are sensible, non-intrusive, and just. work. If only other modules were so nice!

It does only a few things, but it does them <almost> perfectly [see comment by You below], and makes certain aspects of SEO dead simple.

Unless you're doing some special URL re-writing on your site (i.e. more than just using Pathauto and Path), you should have this module installed on your public-facing Drupal sites.

Read more on SEO with Drupal: Search Engine Optimization with Drupal [From Webmaster Tips].