Drupal

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.

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>

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.

I recently accepted a position as an employee at Acquia. I have been "my own boss" since about 2006. I had a brief stint as a part-time employee at a company that has now ceased operations, but for the most part I've been the "owner" of GVS.

Thoughts on GVS

I founded GVS with a few goals. I wanted a company that mirrored open source values of do-ocracy and collaborative decision making. In part this was to make it easy for us to hire community rock-stars and have them feel right at home. In reality that didn't work perfectly though it worked pretty darn well. In part this was because I don't really like being a "manager" and wanted to have an empowered independent team. That mostly worked :)

GVS has had a ton of amazing clients and projects. Some of my personal highlights I'm most proud of are the work on Economist.com, California Closets, and the Drupalcon Chicago site which really helped push forward the COD platform. Not everything turned out perfectly. We had our fair share of mistakes but I think in the end we at least were honest and did our best to deliver what we promised and what the client wanted.

One of the real highlights was that working at GVS allowed me to take a 9 month long trip through Spain, Argentina, Uruguay, Chile, Bolivia, and Peru with my wonderful wife. We visited 30+ wineries, drastically improved our Spanish, and had an amazing time. I've asked every employer I worked for to support me in doing that and none really did. Working for myself I could do that. Of course, it was a lot of work to make that a reality. I had to be aggressive about accepting certain clients that would be flexible with me while I was abroad and on flakey internet connections. I also used that time strategically by investing much more than normal in my community work which has had long term marketing benefits.

So, I'm a Drupal fanboy. Naturally. But there's been some amazing work recently by the Drupal Accessibility Team that I wanted to highlight.

Accessible CMS: Drupal!

According to Drupal's Statement on Accessibility:

This initiative started with advancements with Drupal 7 accessibility. We have committed to ensuring that all features of Drupal core conform with the Worldwide Web Consortium (W3C) guidelines: WCAG 2.0 and ATAG 2.0. Where possible we will also update the previous version of Drupal core, version 6, to enhance its accessibility.

That's a pretty bold statement. Perhaps even more exciting is the Drupal Accessibility Pledge where the maintainers of the thousands and thousands of contributed modules and themes agree that they are willing to work to fix problems if those problems are brought to their attention.

But who can bring the problems to their attention?

CMS Accessibility Team: Groups.drupal.org

Drupal has a large team of accessibility professionals who coordinate their efforts on groups.drupal.org and in irc and other community methods. This group of 374 individuals has been working since 2006 to make Drupal core and it's modules/themes more accessible. The group has over forum threads and hundreds of comments discussing ideas on how to achieve this. It's truly amazing work.

As one of the folks who helps make groups.drupal.org function I'm always inspired when people point to that site as the home of their team.

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)