Drupal

Arcs of involvement in Drupal (or open source)

I've been working with Drupal since 4.6 and was somewhat involved in the process of making 4.7. That was about 8 years ago. Here are some truths I've learned in that time.

There is at least one arc to people's involvement: people go up and people go down

Think about your involvement in Drupal. Did it start at some level, stay at that level, and continue at that same level indefinitely? Probably no. You are somewhere on an arc of involvement. You may be on a mini-arc within a bigger arc. When you first heard of Drupal you didn't immediately jump in and file bug reports and help do usability studies and write documentation. You tried it out. Then you did a little contribution and you liked it (or hated it) but your involvement probably kept increasing for a while. Right now maybe you're headed up or down - maybe you're involvement is decreasing right now because of a big project at work but you know it will increase 2 months from now because your next project will make it easy to contribute to a given module (or core?). Let's look at some real world arcs of involvement.

Let's look just at Drupal Core involvement. I've used the data from marvil07 which includes analysis on commits to the main branch of core (originally CVS and then migrated to git) since 2000. Here are the top committers for the years 2000 to 2003, inclusive:

Person Commits
Dries 2341
Kjartan 334
Steven 157
jeroen 102
natrak (pseudonym of Kjartan) 82
ax 9
Jeremy 9
Marco 6
Kristjan 4
moshe weitzman 4
Al 3
Gerhard 2
Gabor Hojtsy 2

Holy cow. I only recognize 8 of those 13 people, but they are the foundations of Drupal for the first quarter of it's life. Let's look at the next 3 years: 2004 to 2007.

Person Commits
Dries 3537
Steven 1048
Gabor Hojtsy 894
drumm 655
killes 557
chx 331
webchick 124
pwolanin 93

New option for funding Drupal contributors: Gittip

OK, so it's not really "new." It's a little over a year old, but the Drupal community on Gittip just recently got over 150 people which is the threshold where Gittip starts displaying members of the community.

So, congratulations to the Drupal Community! (and to Gittip).

Why is Gittip a useful tool for the Drupal community?

I think a lot of people want to give a little support (via money) to the people who work on Drupal but there is a lot of friction in the way of giving money. Does the person use Paypal? What is their PayPal email? What if you only want to give someone $10? The friction of that whole transaction far outweighs the $10 gift.

There's also a mismatch in the action: most payment systems like a check or PayPal are used one-time (again, because of the friction) but the benefit from a contribution and the desire to pay back that benefit live on for as long as you have a Drupal site. A lot of these topics are discussed in an old Lullabot Podcast where they point out that if every active user of Views gave Earl a few dollars for their use of he'd have a bit over $2 million.

My perspective is that it hasn't been easy enough for people to give that money and the friction is holding them back. Gittip solves a lot of these friction problems and the timing problem by making it easy to do small recurring payments to anyone on github or twitter.

One example that Dries requested: let's help AlexPott extend his "unemployment" and let him focus his genius on Drupal 8 core development!

What does the evolution of our use of Gittip look like?

Among the people who have joined the Drupal community on Gittip:

Helpful functions for writing Drush commands

There are lots of great tutorials out there for how to use drush, but not as many about how to write Drush commands. I periodically dig in and find useful drush functions, but then forget them a month later when I'm writing a new drush command.

So, here is a helpful list of Drush-specific functions that will make your life easier.

  • drush_log - note that the second argument is the type of notice and it can be a 'notice' by default or 'warning', 'error', or 'success'.
  • drush_confirm - ask people if they want to do something. Users can override this by adding a "-y"
  • drush_prompt - prompt the user for some input like a filename or a date value
  • drush_choice - send the user a list of prompts like the 'drush cc' command presents you a list of caches you might want to clear out.
  • drush_user_abort - break out of a command if a user aborts the operation.
  • drush_get_option - check if the user provided an option on the command line like -h
  • drush_set_error - throws an error so the user sees it and the drush script ends with an exit status of 1
  • drush_print - prints out information

Some helpful resources:

  • The drush.ws website is of course full of useful information
  • The Commands doc page ships with drush and is available on drush.ws

The History of Drupalcamp Colorado

  • In July 2007 we had a Drupalcamp at an office in Boulder (photo) with about 15 people. This was intended to cover more advanced topics than we got into at a normal meetup.
  • In November of 2007 there was a last minute camp that turned into an issue queue tutorial led by ajk.
  • In 2008 the camp grew to about 100 people at Denver Open Media's facility on Santa Fe
  • In 2009 the camp grew to over 200 people at the DPPA events center and was also an "ubercamp"
  • The 2010 event was over 300 people at the Auraria Higher Event Center and we even archived the website
  • The 2011 event was over 420 registrants again at AHEC and, again, we archived the camp site
  • In 2012 Drupalcon Denver took the place of the normal event, but some folks actually went camping
  • For 2013, Drupalcamp Colorado is happening again

7 years of events. Amazeballs.

In the closing session of Drupalcamp 2011 I included some photos and stats about signups at camps over the years.

Jenkins + Drush + Dropbox = Easily share sanitized database projects

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

Using Drupal's Meta tag module for Facebook Open Graph, Google rel=author, and Page titles

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.

Drupal is the largest open source project ever - the evolution of marketing exagerations

In an article about Drupal's security process my colleague Jam made the claim that Drupal was the "the world's largest open source CMS." I was dubious at first, but his claim has some merit. The first paragraph of his article links to a study by Henrik Ingo of openlife.cc.

The study compared the projects on metrics like:

  • developers active /day
  • commits/day
  • loc/day
  • developers active / month
  • developers active all time
  • companies all time

Using those metrics Henrik declared Drupal to be one the largest "CMS" project and one of the largest open source projects (approximately 6th overall). However, there are some weaknesses in the study. The study has incomplete data about Drupal (missing devs/day, locs/day, companies all time) and probably incomplete/innacurate data on the other projects. The study was limited to a subset of total projects and only 2 CMS. In comparing the CMS, it considers Wordpress core only but seems to be looking at all Drupal contributed modules when calculating commits/day (or it sampled a very active day for Drupal core!).

If Henrik is interested I would be very willing to get him the data he needs from Drupal to do a more accurate comparison of CMS projects. To be clear: I think Henrik's analysis is very interesting and useful but could be improved to be more accurate.

Bold claim heads towards a lie: Standing Cloud's Drupal Press Release

Standing Cloud wrote a press release which was printed verbatim by other "news" sources like sfgate.

<

blockquote>

Syndicate content