Media

The "summary" list is Views is a really handy feature, but unless it is properly configured, it can lead to an inconsistent experience for end-users. The goal of this post is to demonstrate how a little bit of configuration can provide a very consistent user experience. Here's a quick example of what I'm trying to avoid: consider the following content type called, "Food": As you can see, it is a very simple content type, with only a single added field, "field_food_type". This text field is set up to require the user to select one of its options. When creating a view to show all "Food" nodes, there might be too many to display all at once - you'd like to break up the view by food type in order to allow the user to drill down to the food they're looking for. Using a single Views 2 "Page" display, this is easy to do - just add an argument for the food type and have it display a summary when no argument is present: This will result in the showing only the food types when the page is displayed with no arguments: When one of the food types is clicked on, you'll see a list of matching foods: This works great and is easy to set up if this is what you're looking for. However, I find that often I'd like the summary and a listing of matching content to be displayed at all times. When there is no argument present, then I want a paged list of all the content as well as the summary. When an argument is present, I want the filtered content but I still also want the summary. This can be quite easily done using a display attachment.

I recently had a site that I do volunteer work for ask me if I could create an image slideshow for them on the home page of their Drupal 5.x-powered site. They wanted to showcase various large images on their homepage fading from one to another, as well as be able to control what images were contained in the slideshow. The solution had to be easy to use and maintain as they don't have a dedicated IT person on staff.

Looks like some MySQL data export/import operations can fail for anonymous users. I just did a data dump from my local development server to the live site and all the comments by users who aren't logged in were not showing up. Gone. Missing. It turns out MySQL was trying to stick the autoincrement value in the `uid` field in the place of the supplied `0`.

One of the most frustrating things about Drupal's current architecture is that comments, and the form to post them, are attached to nodes and don't easily allow you to move them around in your TPL files. There really should be an easier way to just place them anywhere you'd like. Most times this doesn't get in your way, until you want to do some fancy layouts where your content is split into multiple columns on the page.

When using taxonomy to group nodes on your Drupal site, you find a need to apply another taxonomy term to all of those nodes (possibly from a different vocabulary) there is nothing that is going to be shorter and sweeter than some quick SQL-fu.

If you're like me, most of your projects are redesigns of existing sites. And if the site is already on some kind of CMS, this means importing content from the old system into Drupal, and to make it easy you'll do it with MySQL directly. There are pros and cons about this approach, which I am learning, and one of the cons is that content created by the database may not always get plugged into all of Drupal's various tables. Sure, you got the text into node, node_revisions, can your CCK tables, but there is more than meets the eye.

Today's challenge: your editors just handed you almost 200 taxonomy terms to add to the site, and you don't have the time or inclination to hit the taxonomy/n/add/term page for the next 2 hours or so... AWK to the rescue! Doing a simple CSV export of the term_data and term_hierarchy tables, you've got a pretty simple structure: term_data tid,vid,name,description,weight term_hierarchy tid,parent What you'll ultimately generate here is a file that stores everything you need to know about importing these terms via a CSV - the term names, the weights, good IDs, and the TID of the parents. 2048,#the current value of the sequences for term_data term,34,Blogs,#a helper line x,1,Drupal,All about Drupal,-5 x,1,Modules,Ways to extend Drupal,-4 x,1,Themes,Making your install pretty,-3 term,35,News,#a second helper line x,1,International,,0 x,1,Local,,0 x,1,Hyperlocal,,0 In this file, we've got 3 types of data: The starting value for sequences The id of the parent term for the next several rows, starting with the word "term" followed by the TID and the plain English name just to help us get organized The new terms, with an "x" where the new TIDs will be placed, and the VID, Description and Weight all filled out.

When defining Content Types in Drupal with the Content Construction Kit you are able to add select boxes to them with CCK. It takes its key/value pairs in this format: Key|Value . One of the most common tasks for this is to create a drop down list of US States. So to save folks some time, I have compiled a list for you to paste right into your own projects. The attached text file will give you US States in the expected format. Hopefully this will save others a bit of typing when you need such a list for your own Drupal projects. Enjoy!

When developing Drupal themes, there is one bit of code you type over and over again: sites/all/themes/blueprint/images/whatever.jpg Where images/whatever.jpg could be a css file, or other file, but is normally an image. However, since clean URLs in Drupal appear to make fake directories, the web browser thinks your image is located in: node/345/sites/all/themes/blueprint/images/whatever.jpg When it's not. Luckily Drupal has tools to help you in this case.

This is rather self-serving, but I actually got quite a bit of traffic on this site in the last few days, and that made me wonder if some older posts I've written on my personal blog were worth anything. There was really just one useful one: