Drupal planet

I recently wrote about setting up Jenkins. My next step was making it do something useful to help our team become more efficient. In most any team it's likely that you'll get some folks for whom "just use drush sql-sync" is not a reasonble solution.

My goal: get a database backup into dropbox on a regular basis and make sure no sensitive customer data is in that backup.

Make a Database backup of the live site

We're running jenkins on a non-production server (for a variety of reasons). So, we get a backup of the live database into a temporary scratch database using the drush aliases feature. That process sanitizes it a bit using the sql-sanitize feature of drush. Then we dump out that database.

1. Start with an up to date checkout of your live site's Drupal code
2. Use the multisite feature and create a sites/example.prod/settings.php where the $databases array has a set of read-only credentials to the production database
3. A second "site" at sites/example.scratch/settings.php
4. Setup a Drush alias that points to those two sites inside the Drupal - be sure to use the 'uri' element so that drush knows which set of credentials to use inside the sites/ folder:
   
$aliases['example.prod'] = array(
'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
'uri' => 'example.backup',
);
$aliases['example.scratch'] = array(
'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
'uri' => 'example.scratch',
);

5. The example.scratch credentials should point to a "scratch" database that is used just for these purposes.
6. Finally a line in the Jenkins job to copy the database from the live site to the backup.
   drush sql-sync @sitename.prod @sitename.backup

Meta tags have gone back and forth in terms of their usefulness for promoting your site. In the late 90s they were a way for nascent search engines to easily categorize sites, then they were abused for keyword stuffing unrelated to page content and their use waned, but they are back again with three major purposes: Facebook Open Graph, Google Authors and Page titles. These are not necessarily "SEO" purposes, but the goal is ultimately the same: making sure that your site puts its best foot forward to gain new visitors.

Metatag module setup

The basic Metatag module setup is pretty straightforward. Download the latest version from the metatag project page. If you don’t have them already you will need the CTools and Token modules.

Setting up Metatag for Facebook Open Graph

There were a few different things I wanted to achieve with the Facebook Open Graph support. Basically, whenever someone includes our page on Facebook I wanted to make sure that the title, description text, and image that Facebook pulled in were the best possible images. I expect that most of the "liking" will occur on our card landing pages. So, I enabled the "Meta tags: Open Graph" sub-module that is included in the main Metatag module. Then I added a meta tag default for the "Campaign" node type by clicking on the bright "Add a meta tag default" at the top of the page on the page at Administration - Configuration - Search and metadata - Meta tags.

This post was originally written in June of 2007 on pingv.com. Since that company is no longer in business, I revived it from the web archive. Thanks, web archive!

We've been in hiring mode for a while now. As most any Drupal Service provider will tell you, there's big demand for people and companies that have an expertise in Drupal. There's also a bit of a shortage of people to satisfy that demand. We've decided on a strategy of hiring great people regardless of Drupal experience and then getting them plugged into the "Drupal way" of doing things as quickly as we can.

There are really two pieces to that process - learning the Drupal code, API, modules and learning how to interact with the the Drupal community and the social values of that community. I distilled some information into a quick document that gives a guide to what I consider to be required reading and actions for anyone serious about being a full time Drupal developer.

Learn the Mantras and the Standards

"Code is gold." Idle discussion or complaining is not valued and will decrease your karma in the eyes of many. Contributing high quality issues, ideally with patches attached, is valued. But don't take the phrase too literally - "Code" is just one thing that's valued. In a big project like Drupal all substantive contributions (e.g. documentation, spam-policing) are valued.

Well, here we are. Drupal 7's release is imminent and once again here are some statistics for folks to review. This is a truly amazing feat: over 950 people were credited in the commit messages as a contributor to Drupal 7. There were, of course, several thousand people involved in the issue queue but a mention in the commit message is reserved for people who did a serious amount of work whether that was writing code, design, reviewing, creating tests, writing text (i.e. documentation), or some other form.

Analysis of the Drupal Commit Data

Here are some items I noticed.

• There were 954 people mentioned.
• A total of 10,091 mentions in 6,117 patches means that there were about 1.6 people per patch
• The top 10 people were mentioned in 30% of the commits
• The top 20% were mentioned in 85%
• People with 3 or fewer mentions form a group that are responsible for almost 10% of the mentions; we can't discount that long tail!

If we group people together into 9 somewhat logical groupings we can see this classic distribution.

You can get the file as an OpenOffice.org spreadsheet (.ods) or from Google docs

The top 10 Drupal 7 Contributors (as measured by this method)

One measure of the momentum of the fine Drupal project is the number of people who are creating contributed modules on drupal.org.

The Drupal contributed projects are stored in a system called CVS and data about that is stored in some database tables that keep track of each change by each person. At the request of some fine folks who are working on important things, I got interested in the idea of the trend related to people committing code to the drupal.org CVS server. Here is the data graphed by the number of committers per month. It is not the number of commits, which would show how active those people are, but the number of people which shows how big of a group of people is doing this work.

Also, this is only about the contributed module and theme area and not about Drupal core. Drupal core commits are done by a very small group of people after that small group reviews the code contributed by hundreds of contributers. So, this really shows activity of the non-core projects.

I've labeled 4 points on the graph.

1. 2006 through Drupal 5.0 slump

Point 1 shows a peak at June of 2006 followed by a slow down until the trough at August of 2006 and then some small increases until December of 2006. Then there is a huge increase in people in January and February of 2007 which is also when Drupal 5.0 was released.

2. 2007 Follows a similar contribution trend