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 »

Drupal is a great platform for building web sites as it can quickly and easily get a site up yesterday. Eventually, some customization will need to be made to a website's code to implement evolving features and designs. A small markup change here, a text alteration there, or modifying a function like user_load(), and in most cases Drupal will continue to work fine. While all might seem OK, without realizing it, your site has been Hacked!

Well, not hacked in the way that a site is broken into maliciously, but hacked in that Drupal itself or contributed modules have been changed on your site. Without knowing what has been changed, it can be very difficult to track down bugs, as the code on your site is no longer the same as the code everyone else is running. Updating Drupal or contributed modules becomes a huge hassle, and important security updates are often ignored due to the work involved in re-implementing code hacks.

The Hacked! module is best run with the Diff module, though it's not required. After downloading and enabling both modules, browse to Reports > Hacked (for Drupal 7) to generate the site report.

It looks like someone has hacked Drupal core. Let's click "View details of changes" and see what's different: read more »

The ability to have images as menu items sounds like a common and straight forward task. Surprisingly, Drupal never has had this ability built into core, but there are a few modules that will help us accomplish our goal. Sprite Graphic Menu is probably the easiest one to use and the one that will be covered in this article.

It is possible to write some custom code using regex in your template.php which could parse the title field of a menu item to look for image filename extensions and then alter the menu output to print that menu item as an image. But wouldn't it be nice if a module could extend the current menu system and provide an image upload field. Even better, how about some CSS options to provide our own sprite background positioning. This is exactly what Sprite Graphic Menu does for us.

The current process is a bit janky and will hopefully be improved. Example: You will not see the image upload field when first creating a menu item. You must create the menu item and then edit it, then the image upload and configuration options will be displayed on the form.

read more »

Building web services and exposing APIs to access your site's content is the new hotness of site building. The work of actually building the custom information feeds that drive those cool features can be daunting, however. Enter the Views Datasource module: it allows you to output content lists built with the Views module in a wide variety of standard web formats.

Setting up Views Datasource is straightforward; create a normal field-based view, then set up a Page display for it and choose one of the Views Datasource output styles. It can create feeds in RDF, XML, and JSON formats and supports a number of common variants of those types like FOAF, OPML, SIOC, hCard, hCalendar, and more. Once you've chosen an output style, you can tweak a variety of settings exclusive to the format: escaping policies for rich text, header and footer data, and so on.

read more »

I initially wrote this article when we completed the upgrade and redesign of this site. However, at the time I felt we were so close to seeing a Drupal 7 release that it was somewhat irrelevant and could possibly deter people from getting involved with Drupal 7. After listening to Lullabot Podcast 90: Drupal 7, Are you ready? I realized that there are still a number of sites out there that may not be ready to port to Drupal 7, but are in fact built on Drupal 5 which would greatly benefit from moving to Drupal 6 for a number of reasons. Here are just a few:

• "Only the current and one previous version of Drupal are actively supported, currently 7.x and 6.x. Upgrade if you are using an unsupported version of Drupal."
• By now all major Drupal 5 contrib modules have a Drupal 6 version (if not a Drupal 7 already).
• UI improvements in both core and contrib make managing Drupal much easier.
• By upgrading to Drupal 6, you're one step closer for being ready to upgrade to Drupal 7.

Basic Background

Many blog post have been written about this procedure. So here's a quick overview for a process that most of these articles have in common. read more »

If you're on our mailing list, you were one of the first to know about Lullabot's new video training site: Drupalize.me. We're really excited to offer streaming access to our entire Drupal video training library with a monthly subscription membership. The Drupalize.me archive currently contains 82 videos and over 118 hours of Drupal training content including the highly acclaimed Lullabot Learning Series, and all of the presentation videos from the Do It With Drupal Conference.

No need to wait for DVD delivery or giant file downloads. Membership will give you immediate access to the entire archive.

Our Lullabot Learning Series videos typically cost $75 to download and $80 on DVD. Drupalize.me gives you access to the entire library of Lullabot training videos for only $55/month. So if you only watch one video per month, you'll still be saving money.

The Drupalize.me videos cover a vast range of Drupal-related interests including Drupal site building, administration, theming, CCK, Views, jQuery development, Drupal performance tuning and security, community building and management, project management, and our famous Do It With Drupal fantasy site videos where we rebuild famous websites such as Flickr, Twitter, YouTube, and Craig's List in Drupal. And we're working on more videos for Drupalize.me right now.

Whenever I visit Drupal events, people come up to me and say how much they've learned from the Lullabot training videos. We're really excited to be able to now offer these videos at a fraction of the cost through the new site. We hope that Drupalize.me will be a great resource for anyone who wants to increase their Drupal knowledge and learn to build amazing Drupal websites.

For more information, visit http://drupalize.me.

With the multitude of single sign-on modules out there for Drupal, it's easy to miss the fact that Drupal has a built-in single sign on mechanism already. No modules, no configuration, just 20 easy lines of PHP in your site's settings.php file. This solution works for a lot of clients, but the set of requirements is pretty specific as to when you can use this approach. This includes:

• The sites sharing a single log-in must be on the same domain. For example:
• www.example.com
• forums.example.com
• subsite.example.com
• You must be using MySQL.
• Your sites must be on the same hardware cluster to be able to query each other's databases.

If your site fits within those requirements, you're on your way to simple, efficient, and easy Single Sign-on!

The concept for this single sign-on approach is based around Drupal's ability to prefix database tables. As you may know, you can run multiple Drupal sites on the same MySQL database. However, most sites are not configured this way, each site is given it's own dedicated database. Drupal's table prefixing can be combined with MySQL's ability to query across databases to make a simple "shared table" across multiple sites. Then you just need to set a cookie domain so that the two sites share session information and you're done! read more »

We've had many requests for sample videos from the Lullabot Learning Series. We decided to post an entire chapter from each video. We tried to pick a chapter that was full of useful information on its own and we placed them on both YouTube and Blip, so feel free to spread them around and embed them on your favorite web page.

Hope you enjoy these videos!

Learning CCK for Drupal

In Learning CCK, Jeff Eaton, Nate Haug, and James Walker show everything from CCK basics such as adding and displaying fields to more advanced topics such as CCK’s database storage mechanisms, field-level permissions, and how to theme CCK’s output. Each chapter of this video builds upon the last as the team builds and configures the content types for a university job board. This video pairs well with Learning Views, which continues this job board project through to completion.

Chapter 3: Adding a CCK field

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 »