Well, I'm finally home after a week-long trip to Drupalcon Chicago, where it was revealed that the next North American Drupalcon will be right here in Denver!
I had a great trip, making some contacts with various companies and keeping my hand in on what's going on in Drupal. Coming home got a little funky with a missed flight, but even that was overcome and I'm finally back at home.
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:
- First, get rid of git if you've already installed it -
sudo apt-get remove git-coreshould do that.
apt-get install build-essential
- Download the latest version of git.
sudo apt-get build-dep git-core
tar xjf git-184.108.40.206.tar.bz2(or whichever version you downloaded)
- Change directive into the new directory.
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.
This page contains links to the drupal website Music Wow!, which is meant as a website with content to use to demo creating various types of views. It contains two major content types, Artists and Albums. Although the front page doesn't show any content, there is content in the site.
This site was made up in aegir as views.localhost - if you want to use it, you'll want to replace the included settings.php with the default.settings.php as in setting up a new site. You can move everything to sites/default instead of sites/views.localhost if you want to go that way, but remember that you need to move the contents of sites/views.localhost/files to sites/default/files.
Update: The user 1 is username "admin" password "password"
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 .)
Here's where I'm posting the various files that I promised to deliver - these are the files I used in my DrupalCamp Colorado 2010 presenation on extending Solr.
So, I'm finally back home after a week in San Francisco. The trip had two main reasons - one was to attend Drupalcon SF, the other to spend some time visiting my brother in law, Tim. Things went well on both fronts, and I got in some bonus treat as well.
Talk given by Young Hahn - @younghahn on twitter.
This is a talk that focuses on three modules that were developed as part of Open Atrium.
Context triggers reactive behaviors on pages.
Basically, in the past putting content all on the same page was a pain. You have a snippet, say, that says 'This bit should show on blog pages', and you've got it spread throughout your site in half a dozen places. Context replaces this by having a system that asks 'are we in the blog section?'. There's also things like a global context, or a login context. (such as when an anonymous user is browsing).
Context is basically an additive system - a page can be in the global context, the blog section context, and the blog post context.
Note to self - do we need a page that lists all the blogs under all of their contexts for easier display?
The sheer size of Drupal, and of DrupalconSF, was brought rudely to your attention as you walked into exhibit hall A, which looked to be about the size of room you would need to store a few decently sized airplanes, and saw the rows and rows of chairs set out for people to sit back and hear Dries talk about the State of Drupal.
In short, he thinks it's doing pretty good.