drupal planet

The problem I was handled at work was pretty simple - we're putting together a multi-language site, with English and Spanish data. However, if you search on something that's part of a proper name which shows on both English and Spanish data, then you were getting a mix of English and Spanish nodes. What we wanted was a way to automatically filter the search by the current language, something that I couldn't find anywhere. So, I rolled up my sleeves and created this:

Here's a useful module that I keep forgetting the name of, so I wanted to note it down: Stage File Proxy. It's not something you use for a live site, it's something you use while developing.

The basic idea is this: you're working on a site that's since gone live, making changes for the client. It's easy enough to get a copy of the database, but the files can be a pain to keep replacing, interlacing test files with live images. Stage File Proxy fixes this by snooping in on imagecache and, when a file is missing, then it grabs it off of the live site, copies it to the local directory, and then you've got the file locally and all your imagecache files get generated for you!

There's a version for six and for seven, and there's no ui for it yet, although there is a patch for it. Then again, once you've got the simple settings done, you don't need to worry about them again!

Here's a quick snippet I just found out today: The jquery cookie plugin is presented as part of Drupal 7. This is really cool and useful, but I must note that it's not automatically included on every page load, so you'll want to include it if you want to use it, and as well it doesn't seem to actually be documented anywhere on drupal.org.

Happily, the original documentation for the plugin is at https://github.com/carhartl/jquery-cookie/blob/master/README.rdoc, and is pretty good, although I suggest reading it through at least twice, as at first I missed that you can read, as well as set, cookies with this. Basically the parameters are the cookie name, the cookie value, and then an options object which says the expiration, the path, the domain, and such. Note that the expiration can _either_ be a date, or a number of days.

Hopefully this will help other folks out with using the jquery cookie plugin with Drupal 7.

(I originally wrote this for G+, but since it's long enough, I'm making it a blog post too.)

So, I'm making a new component for webform in Drupal, called 'Multigrid'. It's based on the grid component, which if you don't remember it, allows you to define a set of common options (like, neutral, dislike, hate beyond rational thought) and define a set of questions, and then it sets up a grid of radio buttons, where the answers are across the top and the questions go along the left side.

If you're picturing the online survey you filled out recently in the mistaken hope that you might win $500 after eating at sit-down-chain-restaurant-326, then that's pretty much it.

It's been a very long week to me leading up to Drupal Camp Colorado, but it's been a successful and satisfying one. Over the weekend I complained a few times at people not to let me run three presentations, but honestly, I loved it! Really, I quite like standing in front of folks and trying to teach them something I'm passionate about, and I was lucky enough to do it three times. I may not get to do that again, really - with the way the Drupal community is growing these days in Colorado, more and more people will be available to step up and help out with sessions like this.

Something useful sounding from #drupal-colorado:

<cyberswat> drush php-eval '_field_info_collate_fields(TRUE); _field_info_collate_fields()' ... arrrrrggggghhhh /me curses loudly
<cyberswat> should never have to run that
<cyberswat> c4rl: if you ever have an instance where your installing new fields and instances and every piece of code tells you that everything worked from the update hook but you still don't see the instance then run the above
<cyberswat> that took between 4:00am and now to figure out

<cyberswat> for some reason field_cache_clear(); in field_create_instance() didn't do the above as it should have
<cyberswat> field_read_instances() reads from the db not cache
<cyberswat> so when your drush_print_r ing away you'll see wrong information telling you everything is golden

This sounds like an important thing to remember.

So, I like working on Drupal in virtual machines, and my favorite is to use Ubuntu 8.04, because it's got PHP 5.2.x, which Drupal 6 works with better than it does PHP 5.3.x. Unfortunately, the git that Ubuntu provides us with is from 1.5.x, which doesn't allow use of git clone --branch. And the git
instructions seem to require those. What to do? Happily, you can compile git yourself:

1. First, get rid of git if you've already installed it - sudo apt-get remove git-core should do that.
2. apt-get install build-essential
3. Download the latest version of git. http://kernel.org/pub/software/scm/git/git-1.7.4.1.tar.bz2 works currently.
4. sudo apt-get build-dep git-core
5. tar xjf git-1.7.4.1.tar.bz2 (or whichever version you downloaded)
6. Change directive into the new directory.
7. ./configure
8. make

I continue my work with the Migrate Module, and recently ran into needing to migrate a value to the Link Module. If you haven't gotten into it yet, Migrate generally expects other modules to handle migrating special bits for nodes, except for the CCK module, and that's included both (I think) because it's in D7 core and because it's so bloody common. Field-specific handling is dealt with by implementing a MigrateFieldHandler, which basically sets up the arrays properly. Again, migrate comes with a number of MigrateFieldHandler classes for the core cck fields, but not for custom CCK fields, like Link.

So, having recently run into a link field I needed to migrate, this is a first swing attempt at handling it. Do note that any module that includes this class will need the Migrate api hook that I discussed in my last post, and also note that I intend on including this fix in the next release of the Link module.

I'm currently in the midst of setting up a migration from a pretty huge MS SQL database to Drupal, in D6. This migration not only involves Microsoft SQL Server, as I mentioned, but it also involves using mongodb, so we're basically touching three different databases here.

So, I've been using the 2.0 branch of Migrate for 6.x, because I was curious about seeing it again, and I know it worked quite well for Examiner. (Yes, they were doing Drupal 7, but it was still the same basic idea.) It's been going very well.

Today I updated to the 6.x-2.0-beta3 version of the code, and I had to make a couple small changes to my existing module. I'm reproducing them here, in hopes that it can prevent others from having trouble like I did.

I've recently been digging into the Aegir Hosting System, both because we're starting to use it at my current NREL gig, and because I've proposed to do a session on it at DrupalCamp LA. In short, Aegir allows you to easily administer a number of Drupal sites from a common site, itself built on Drupal. It's really slick, and a lot of the functionality is built on Drush. (Also see http://drupal.org/project/drush .)