When Drupal users deploy their first (or second, or tenth...) site to a real web server, one of the most common points of confusion is the proper access permissions for the files directory and settings.php. Because the files directory stores uploaded content from the site's users, badly configured permissions are a potential security risk. Lock it down too tightly, though, and managing backups or future migrations can be a pain.

My standard starting point when creating a new Drupal site on a server is to create or select an existing user that is a part of the web server group (typically the Apache group), and give ownership of all Drupal files to that user. On Ubuntu, these are the commands to get that set up:

Once I have that set up, I'll log in as the user and install Drupal at /var/www/example/docroot or a similar path, then create the files directory by hand and copy over the settings.php file. Since we log in as our example user before copying in Drupal, our file ownership and permissions should automatically be properly configured on all the core Drupal files and scripts (including .htaccess files). read more »

It was the spinning tupperware drawer that got me. I was in a friend's recently built condo, and he was showing me the ins-and-outs of the build, when we came across the drawer. It fascinated me because it was obviously custom-built to meet my friend's obsessive-compulsive tupperware organization needs.

"Was this drawer design in the blueprint?" I asked.

"No," he said. "I just happened to come in when the builders were working, told them what I wanted, and they built it!"

I was shocked; I had always thought you gave the builders a blueprint, told them the colors and textures you wanted, and they built it. At that point, I'd thought, you pretty much get what you get.

In the web world, this is how projects often go. The client needs a website, and the client hires a vendor to help. A blueprint and design is created, the vendor builds the website, the client is trained, and from then on they're responsible for maintaining and improving themselves. This may be the ideal scenario for some projects, but it can be extremely risky when working on complex project with many unknowns, when using open-source software, or on agile projects that require frequent adjustments. I find that enterprise projects are most successful when both the client and vendor are equally engaged during the development process. Ideally, the client has a committed development team for the project, as if it was an internal project, and the vendor team acts as an extension to the client team. read more »

Does Google's "duplicate content penalty" harm Drupal sites? No! Here's why.

For years, Drupal has enjoyed a solid reputation as a search engine friendly CMS. It generates relatively clean, standards-compliant HTML out of the box; syncs up the important TITLE tag with semantically useful H1 and H2 tags in the body of each page; and provides short, human-readable URLs with plentiful options for customization. (Anecdotal evidence: several years back, I wrote a post on my Drupal-powered blog that mentioned the name of the company I worked for. Within two weeks, my blog post ranked higher than the company's own web site on Google.)

Recently, I've witnessed a number of discussions where people expressed concern about the way Drupal generates the human-readable URLs that help make it Google-friendly. In particular, they were worried about Google's dreaded Duplicate Content Penalty, a system designed to keep spammers from flooding Google with the same content at dozens (or hundreds!) of URLs. There's a lot of confusion floating around, so for the geeks in the crowd (and the not-so-geeky interested in learning how things work behind the scenes), I thought it would be useful to give a guided tour of how Drupal manages and generates URLs. read more »

Using the delightful combination of Image and Image Exact Sizes modules, two parts Views, and a dash of theming magic, you too can have your very own Flickr clone... in Drupal! This recipe will show you how! read more »

As I was working on cleaning up a few isses for the Javascript Tools module, I stumbled upon one issue dealing with overriding CSS styles. In this case, JSCalendar was adding it's styles after a theme's styles were being loaded. Obviously, from a CSS standpoint, it would be impossible for the theme to override and change CSS styles in JSCalendar. This needed to be fixed.

After some digging, I found this comment that explains this problem in more detail and outlines the correct procedure for modules and themes to add CSS files.

To summarize Tom:

Want to create a front page that's styled differently from the rest of your site? Perhaps you need a separate admin theme? Or how about a login page which only shows the login block and nothing else? With a little PHP knowledge these problems are easy to solve. read more »