Tutorials

As part of a Drupal workshop that I'm teaching (the Drupal Career Starter Program), we've been discussing Acquia Commons. Our discussions led us to decide to have a local meetup specifically to learn more about it.

Since we expect a number of newbies at the meetup, I figured I post a quick video showing how to get Commons up-and-running using Acquia Dev Desktop. I found it to be a little bit tricky, mainly because the memory requirements for Commons are a bit higher than for core Drupal. The video shows how to tweak a couple of memory setting in the php.ini file.

NOTE: If you're using the Windows version of Acquia Dev Desktop, you can ignore the "apc.shm_size" change - it isn't used in Windows!

This guest post was written by Ben Hosmer, a Drupal user new to module development as well as an active member of the Florida Drupal user community. He often blogs about Drupal related topics at radarearth.com

Let's face it - anyone with anything more than a passing interest in the Drupal community is probably aware that we're in the midst of embracing Git, "the fast version control system". As with just about everything else in our community, we are continuously jettising outdated technology and replacing it with modern solutions.

Creating a well-organized, content-heavy website is difficult. Creating one that is also sustainable is even trickier. It's easy to keep adding features to a web site without considering how they fit into the overall plan until you get to the point where things start getting out-of-hand and site maintenance starts becoming a real issue (blame Drush for making it so darn easy to add new modules!)

One of the primary ways of keeping a Drupal site of any size running securely and at peak performance is to ensure that all of its modules stay updated. With thousands of modules in the Drupal eco-system, updates are released literally every day. Luckily, Drupal core's Update Status module helps site administrators keep notified of modules in need of updating.

In an attempt to point to some of the great things that are available using Features, I tried to look for a directory of Feature Servers. Sadly, Google was not very helpful. After some digging, I was able to locate a page on the OpenAtrium Community site called Distributed Feature Servers. This points to many of the other pages I was able to find via search.

Utilmately I created a wiki page on the Packaging & Deployment group of groups.drupal.org, which seems to be one of the hottest places to discuss Features.

Directory of Public Features Servers wiki page

Currently, there is tons of info about how to create your own Features Server, but not much about where all the publicly available features servers are located. If you know of others, please go edit the wiki page on groups.drupal.org or leave them in the comments here.

This is your moment, you've decided to step up and make a job board for your local Drupal User Group. You spend some time thinking about everything you'll need, including the job listings themselves. You'll want to gather the standard info, like job title and job description, salary, experience, the works. When it comes to gathering company info, your instincts make you take a few extra moments to plan.

If you think about this from the perspective of the person posting 6 or 7 jobs, she would end up having to type (or at least copy and paste) the business' contact information each time. If you think about collecting 3 or 4 fields for each business, then that's about 20 extra form fields for the user to fill out. If she then decides to change the info, let's say she made a typo, she now must click through each edit screen 6 or 7 times. That amounts to hundreds of clicks and several hundred repeated keystrokes.

There must be a better way. A nodereference can help your users.

Once finished, you will have two nodes, one for a job and another for a company, and yet you will still display the information about the company inside the job listing.

By the end of this tutorial, you should understand what a nodereference is for, how to create and use one, and finally, how to use template files to theme the output of the nodereference and get the most out of the relationship.

This article is also available in French from KolossalDrupal.

There's an incredible amount of functionality that can be provided by the Views module, especially when it is combined with intelligent use of Node Reference fields. When you relate your site's nodes with Node Reference fields, these relationships can be easily leveraged to create some very useful views.

I'm going to build a view for a sample music site. In the site, I have 3 related content types for "Band" nodes ("Black Eyed Peas", "Linkin Park", etc...), "Album" nodes ("Back in Black", "Bat Out of Hell", etc...), and "Events" (concerts, television appearances, etc...)

In the first three parts of this series, we've looked at what RDF will do for you as both a consumer and a provider of RDF data and we've had a quick primer on what exactly implementing RDF entails. Turning our attention back to Drupal, this article will take a look at the state of RDF in Drupal 6 and some of the available contribued modules. Tomorrow's article will take a look at what the next version of Drupal will offer in terms of RDF.

Drupal 6 does not have any RDF functionality in core. If you want to implement anything having to do with RDF in Drupal 6, you'll need to utilize contributed modules. Only a few of the RDF-related contribued modules for Drupal have even had official releases - the majority of them are still somewhere in the development process.

While reviewing the existing RDF modules for Drupal 6, I found that I could categorize them into two categories - "Provider Modules" and "Consumer Modules". Those in the former category are designed primarily to help you RDF-ize your site's content. Modules in the "Consumer" category are generally designed to help you consume, use, and display RDF data from various sources. In some cases, there is some overlap, so this categorization is more for convenience than anything else.

If you've read the first couple of installments of this series, you should have a pretty good idea of what the "semantic web" is by now. By providing precise meaning to a site's content, applications can take advantage of these machine-readable hints to link data together across sites in a myraid of ways. Before you jump in the deep end of the semantic web pool, there's a few more things you should have a clear understanding of.

As I previously defined, RDF stands for Resource Description Framework. This is a family of standards for describing content on the web. The vast majority of current and future Drupal implementations of RDF are actually RDFa (Resource Description Framework in Attributes), a set of extensions to XHTML. RDF is normally implemented using XML; while this is possible with Drupal, RDFa allows Drupal to implement RDF as part of the standard content displays.

It could have been an April Fools joke.  On April 1st we got the call. "We have mockups for the design of the site, and we need the theme done in 2 weeks. After that we can discuss the XML import part of the project. We need to go live at the beginning of May."  We knew it would be a challenge, but we made it happen - on May 7th the site went live.

Sometimes in our lives, we all have pain, we all have sorrow. And sometimes we also have to launch Drupal sites into the wild blue yonder. It's during these times that we separate the grown-ups from the n00bs, and we see how well our site performs under heavy load. Many of us didn't need to worry about speed, page size, and server load in our younger years when we were building sites for Uncle Don and Aunt Sue, but eventually you get that big client, and you need some help.

Testing your site's performance

There are several ways to test, and a few metrics to acquaint yourself with. Not all metrics are created equal, but all of them are important at one time or other. In Part I of this post, you will be reading about testing with the Apache Benchmark tool on the command line.

Rounded corners are all the rage - and they have been for quite some time in web design. The way they "soften" up a design make them quite attractive to designers and decision-makers. Unfortunately, implementing rounded corners in a web page is not nearly as easy as it is to implement in a mockup using an image application.

When talking about rounded corners, there are 2 distinct user cases to be considered - the first is when creating rounded corners only on the top corners of an area - this is commonly seen on tabs and block headers. The alternative use case is when all four corners of an area are rounded - this is usually seen in blocks and around content areas. This article will focus on the the case where all four corners need to be rounded. The result will be a method of adding the ability to optionally apply a rounded border to any block on your site in a way that doesn't break when the block is resized.

By the end of the article, you should be able to add this option to just about any Drupal theme - the relevant files you'll need are available for download at the end of this article.

Keeping a site's design as clean as possible is something all (well, okay, maybe not "all") designers and developers strive for. One relatively easy thing that you can do towards this goal is removing the supporting (and often unnecessary) text around your site's search field. I'm talking about the "Enter search terms" or "Search this site" text that floats innocently above or next to the text input box. Is this really necessary? I don't think so.

A much cleaner way of presenting a search box is with some default text inside the input field that automatically disappears when the user moves the cursor into the field.

Ubercart is arguably the leading ecommerce module suite for Drupal. It allows site admins to sell virtually just about anything online, including physical products, downloadable products, and event admissions. Often, when selling event admissions, it is desirable for the registrant to be able to fill out a profile during the checkout process that can be posted on the site once the transaction is complete. The UC Node Checkout module was built for this purpose. This is the way last year's Do It With Drupal conference handled registrations - with these exact modules.

Setting it up can be a little tricky, as it is not entirely a straight-forward process. Ryan Szrama, the de-facto leader of the Ubercart project, demoed this module during the recent DrupalCon DC. I thought I'd take the time to reproduce what Ryan did, as it is a great introduction to this module. Keep in mind it won't be an exact reproduction, but it should be pretty close.

This article will assume you're familiar with some very basic Ubercart concepts, if you're not, don't worry, this isn't rocket science. One thing you'll need to do if you're playing along at home is to create the "keys" directory for test credit card payments - full info on this is located at admin/store/settings/payment/edit/methods in your Drupal install (assuming you already have Ubercart enabled).