Drupal planet

Drupalcamp Colorado 2014 Preview: Large Scale Drupal

This year, Drupalcamp Colorado is taking on the topic of "Large Scale Drupal" - a phrase that was popularized by Dries Buytaert. We're taking that phrase and using it in a generic sense to help set a focus for our event.

Matthew Saunders wrote a great overview of the camp, so if you're interested and need more convincing to come, read that. This is an update on our tracks and some great sessions that have been accepted already.

Tracks and session submission requests

We're taking that theme as inspiration for our sessions which will be across 4 tracks:

  • Business and Open Source
  • DevOps
  • Commerce
  • Design and Front End
  • Development and Site Building

Today we are excited to announce the first 9 sessions that have been selected. Session Submission is still open until July 11th. We've currently got too many sessions in /Development and Site Building/ and not enough sessions in the other categories. So...if you have something to say in those other areas, please submit a session (note, you have to login first, and you should register too).

First sessions that have been accepted:

There are some sessions we know we're going to accept because they come from great presenters on popular topics that match our theme. Below are the 9 sessions we knew we could accept now.

<

ul>

  • Solution architecture: designing a strategy for project success by Diana Dupuis, Amazing CEO of Amazee Labs in the USA
  • Data Analytics and the Day After by Ron Lin, CTO and Co-Founder of CARD.com
  • 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:

    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 for Seasoned Professionals - A Quick Guide to Code and Community

    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.

    Contributors for Drupal 7 - Final Numbers*

    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.

    Mentions People at that level
    1 435
    2 144
    3 71
    5 89
    8 65
    14 50
    23 40
    56 40
    213 20

    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)

    Name Mentions
    sun 506
    catch 403
    damien tournoud 398
    chx 324
    yched 290
    jhodgdon 278
    david_rothstein 269
    dave reid 231
    pwolanin 215
    c960657 151

    Contributors to Drupal.org CVS since 2000

    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.

    Contributers to drupal.org contributed module repository

    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

    Syndicate content