Kristjan Jansen

Almost a year ago, in Oct 2010 I made a presentation about Drupal history in the first ever Drupalcamp Baltics conference. In some hazy reason I never published the slides. Just found them today, so it's time for a Drupal Time Machine again. Check out those young faces, long-lost archive screenshots and other curio from the Drupal glory days. Here are the slides:

Short History of Drupal (3.6 MB PDF)

Want more? There's also an agentrickard's talk Lessons from Drupal 3 from Drupalcon Chicago.

Now and then in Drupal-land we encounter ideas what are already tried in the past. This includes recently introduced Git sandboxes – temporary project spaces what can contain experimental stuff: prototype code, alternative takes on modules etc.

Now lets rewind back 8 years: meet CVS sandboxes – somewhat similar concept introduced in early days of Drupal when community of core contributors started to emerge but there were no issue/patch queue as we know it. Also as there were no module/theme versioning at that time, the devs somehow needed to maintain their -dev versions of their code.

So, sandboxes were introduced, located under contributions/sandbox/username where users with CVS write access could store their stuff. It's hard to pinpoint the excact beginning date of the sandboxes, my personal quess would be late 2002 – early 2003 but please correct me here.

But enough of old stories, lets get to the fun part: diggin' some 'boxes. Although both repository viewers, cvs.drupal.org and drupalcode.org are now defunct, CVS sandboxes are still accessible via running

 cvs -z9 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d sandbox contributions/sandbox 

Warning: this gets you all sandboxes, 130MB in total by 292 users.

Here are some findings from my own stash, such as a very rare mockup for Drop.org, (precursor of Drupal Planet) from March 2003:

README states:

This directory consists concept sketches and neccessary image files to to make bluemarine.theme suitable for www.drop.org portal.Unfortunately I do not have time to implement these changes myself, I hope someone will take a lead.

Also there's a usability analysis, redesign proposal and IA for Drupal admin section from Nov 2003 what almost sounds like a D4UX project of the era:

First of all we must ask ourserves – why should we the vistit admin page at first place? What are the tasks we do often? What are the admin sections we rarely vistit? /…/ Current Drupal admin page is a victm of its own über-modularity. All admin links are treated as equal, but in reality they are not. /…/

Note that this is only the beginning, it was the checkout in the latest known state. Checking out stuff using different CVS timestamps or branches could earth more hidden gems.

So what's in your sandbox? Just type the following, replacing username with your CVS username

 cvs -z9 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d sandbox-username contributions/sandbox/username 

and launch your Sandbox Time Machine before @drupalgitgremln pushes it to the void!

There are several SVN users out there who use one single monolithic repo for multiple projects. Let's assume you are maintaing Drupal module [yourmodule] in Google Code SVN repo under trunk/path/to/[yourmodule]. How to migrate only that particular subdirectory to Drupal Git?

There are many ways to solve it, I am going through options A (simpler, slower) and B (complex, faster).

Option A: Git Way

This option is more Git-centric and simpler but could be a slower if you have a massive SVN repo since we are cloning the whole shebang first.

Step A1: Convert a full Google Code SVN repo to local Git repo

git svn clone -s http://[your_google_code_repo].googlecode.com/svn [yourmodule]

Optionally you may want to convert the commiter's usernames to Drupal usernames. To do that, create a file authors.txt and fill it with following

[google_code_username] = [drupal_org_username]<[drupal_org_email]>
...

In my personal case some strange commits had no author, so I had to add following line as well

(no author) = [drupal_org_username] <[drupal_org_email]>

so the command above looks like this instead

git svn clone --authors-file=path/to/authors.txt -s http://[your_google_code_repo].googlecode.com/svn [yourmodule]

Step A2: Get rid of everything inside local Git repo except your module

cd [yourmodule]

git filter-branch --subdirectory-filter 
[path/to/yourmodule] HEAD

git reset --hard

git gc --aggressive

git prune

Optionally you may want to get rid of git-svn-id's what git svn clone has added to each commit message: "git-svn-id: file:///local/path/to/[mymodule]_svn/trunk@[rev] [hash]"

To get rid of this, follow these instructions. To summarize: git clone this https://github.com/nothingmuch/git-svn-abandon, make sure the directory is accessible from $PATH and inside your git repo run

git svn-abandon-cleanup

Surprisingly I had to run this command twice to get the desired effect.

Step A3: Push local Git repo to Drupal.org

Make sure you have set up git access, keys and new project [yourmodule] first (for testing create a sandbox project).

git remote add origin 
[drupal_git_username]@git.drupal.org:project/[mymodule].git

git push origin master

Ta-da, you successfully moved a subdir from Google Code SVN to Drupal Git!

Option B: SVN Way

This might be a little quicker option if you have a gigantic Google Code SVN repo but it's a bit messier to get going.

Step B1: Create local SVN repo

svnadmin create [yourmodule]_svn

(the "_svn" suffix is arbitrary, it's there to separate directory name from future git repo directory)

then run your favourite text editor

mate [yourmodule]_svn/hooks/code-revprop-change

fill it with following contents and save:

#!/bin/bash
exit 0

Then run

chmod +x [yourmodule]_svn/hooks/code-revprop-change

Step B2: Sync a subdirectory from Google Code SVN to local SVN repo

svnsync init --username [google_code_username] file:///[local/path/to/][yourmodule]_svn https://[your_google_code_repo].googlecode.com/svn/[path/to/][yourmodule]

and then (this might take a while)

svnsync sync --username [google_code_username] file:///[local/path/to/][yourmodule]_svn

Step B3: Convert local SVN repo to local Git repo

git svn clone -s file:///[local/path/to/][yourmodule]_svn [yourmodule]

As in Step A1 you may want to use authors.txt in this command and as in Step A2 use "git svn-abandon-cleanup" afterwards.

Step B4: Push local Git repo to Drupal.org

You will know the drill:

cd [yourmodule]
git remote add origin [drupal_git_username]@git.drupal.org:project/[mymodule].git

git push origin master

Note that my personal case was simple: I had no branches nor tags in my Google code repo so I have not tested those more complicated cases. Looking forward for feedback how to do the migration per branch/tag.

References:

http://code.google.com/p/support/wiki/SubversionFAQ# How_do_I_download_my_Subversion_history?

http://help.github.com/svn-importing/

http://stackoverflow.com/questions/433276/svn-repository-split-problem/466039#466039

http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository

My recent oddball piece of Drupal memorabilia, History of Drupal logos got some tremendeous feedback – thanks, guys! – it seems it struck the nostalgia nerve of the community.

Lets continue the quest to dig our CVS treasures and relive those memories. So I proposed a short fun session in Drupalcon Chicago, aligned to the “10 years of Drupal” theme of the conference:

History of Druplicon (Track: Drupal Community, Experience: Beginner)

If it gets selected to Drupalcon (yes, it depends how you vote ;), I'd like to run some interviews with the vets of the community to get more insight into those crazy early days and get the session more personal. You know who you are!

UPDATE: My session was not the lucky one, I'm a no-go Drupalcon Chicago this year.

I was recently asked to bring back memories of early Drupal history, especially the birth of the Drupal logo. For research I found a goldmine: Drupal CVS commit history http://drupalcode.org (renamed from cvs.drupal.org). Combining that with CHANGELOG.txt and my hazy memory here's the short unofficial story of Drupal logo – in full color.

Note that I included some personal notes but I do not want to over-emphasize my role: biggest credit for creating early Drupal visual image goes to Steven Wittens aka Unconed and there are tons of others not mentioned. Thanks for you all!

Also, if you have any corrections to this history – or some funny details to add, let me know via e-mail, Twitter or the comment form below.

I am breathless: considering Estonian astonishingly slow Drupal pickup rate, a first big-name site has launched: Estonian Ministry of Foreign Affairs.

Was it the Drupalgate affair making diplomats finally move faster?

Edit: the conversion was made in-house, with Canadian company Liefa Communications doing design as Photoshop comps.

The title may suggest a bit medieval setting, but do not get wrong about it: in true e-Estonia fashion, every decent wooden shack around Estonia has a WiFi access and a projector to run meetings.

In one rainy Friday, 12 June, first ever Estonian Drupal convention gathered in a forest hideout near capital Tallinn. In addition in lengthy debates on Drupal latest developments and sharing best practices (Artisteer was mentioned, the usual Views and CCK gospel shared), we also talked about infrastructure of Drupal Estonia: g.d.o. group vs regional domain drupal.org (usual debate in every country's community?), releasing a proper Estonian translation (we are almost there) and founding a nonprofit organization to support Drupal Estonia activities. There was even a talk about EU funds to support regional translations of Drupal.

Meet the mighty pioneers of Drupal in Estonia – the detailed links with names and links can be found here.

When I was asked to talk about user experience in DrupalCamp Finland in Helsinki University, I first came up with the long-winded presentation title ever: “Drupal UI challenges: Creating better user experience for Drupal 7 and beyond” – to cover my back obviously – since I did not had much of an idea what to talk about.

I tried to narrow it down to two things: introducing D7UX to Finnish Drupal community and talking about my recent pet peeve: re-usable interaction patterns and user interface components.

You can download the presentation here (2 MB)

Some credits: The font is free Rabiohead. Dude and angel pictures are from Flickr and picture of Chucky is well…from the hell of course!

Recently I was called to help a very special initiative in Estonia: a grassroot non-commerical project My Estonia, a 1-day country-wide brainstorming session designed to provide all citizens to gather around issues that matter to them – from local neighborhood to larger-scale concerns.

I volunteered to help them in data visualization: to take geodata about “My Estonia” brainstorming locations (all 500 of them), split them by county and deliver freely printable maps to usein event headquarters and also distribute them in local newspapers. Since the whole thing had to be without restrictive license, I couldn't use usual “Google Map + KML on top of it” route. So, what to do then? I only had half day to come up with solution.

I turned to Mapping Kit, Drupal's plug-in suite what I noticed in DrupalCon DC presentation – and I was blown away. Although a bit complex at start (especially because of cryptic terminology of geoinformation systems) I was quickly up and running, creating maps, embedding marker layers and querying mapping servers. All I needed was there, and more.

I addition to great backend I was also blessed by very helpful individuals: Andres Kütt and his team to provide a KML with source data (view in Google Maps) and allowing to split it up by county using URL parameters.

Next step was to embed the data to the open source map: OpenStreetMap source map and OpenLayers map rendering – both supported out of the box by Mapping Kit – were both natural fit. I attached each county to separate marker layer so the client could hand-pick the any data combination he needs.

There was still more to tweak: the markers. KML source had a minimal markup and no styling whatsoever. I tried several Google's default markers but they tend all to be too complex and unsuitable for print. I finally decided to create my own simple marker (available here: marker_ball_white_32×32.png).

Now, my map was looking something like this (county layers were accessible under “+” sign):

But something was still missing: the county borders to give a clearer overview what locations belong to what region. I checked out Estonian Land Board, as they are running some geoweb public services. I tried to query their Web Map Server for county borders using Drupal's Mapping Kit and use it as WMS layer in my map. Querying part worked like a charm, but unfortunately the border data was not in the presentable format: filled polygons instead of lines, data scattered across several layers etc.

At that time I was almost running out of time so I gave a call to Land Board where Raivo Alla provided me a helful tips to fix the problem and rendered me a decent KML file with the county borders. The 5MB KML file was unfortunately too big for Google Maps and OpenLayers to crunch (Google Earth made it) so I had to cancel the effort to add county borders to my map. But nevertheless big thanks to Land Board (I am working with them to make the border file simpler and publicly available in their website).

The bottom line is this: if something makes you from zero to “homegrown geoweb expert” in half a day, it must be one hell of a tool. Also, I am glad I live in Estonia where organization structures are not too hierarchic, it's easy to avoid bureaucracy and get the public data you need fast. Thanks to all!

Second video take on content type editing is embedded below: this time focusing more on workflow-oriented fields such as status and author.

Slides can be found in Flickr.