DesignHammer Blog

Charting our bicycling commuting habits

Kosta Harlan — Thu, 30 May 2013 14:18:06 +0000

Happy belated bike to work day! In honor of that day – and National Bike Month, not to mention Earth Day (when we started working on this), and because the weather is just so pleasant this time of year – DesignHammer published a new Sustainable Commuting page. We'll add more content about our overall sustainability practices as time goes on, but for now the first entry is a section on our bicycle commuting habits. From the page:

DesignHammer's Robert Weeks and Kosta Harlan have been cycling to work since 2005 and 2009, respectively. Robert takes a 17 mile round trip route to work while Kosta's commute is 15.6 miles. Both of them feel fortunate to spend some of their cycling commute on the American Tobacco Trail.

In 2011 we started tracking the miles we were putting into our routes in a Google Spreadsheet. Now that we've accumulated some data, we thought it would be interesting to visualize our sustainable commuting habits over time, and to measure our impact on reducing carbon emissions – the average car emits 4.8 metric tons of CO² per year, so far we've offset 1.72 metric tons of CO² through bicycle commuting a total of 4108 miles. (To put that in perspective, a metric ton of CO² is about the size of 35 Toyota Camrys.) Factoring in DesignHammer's flexible working arrangement where team members can work some days from home, the total emissions offset increases by about one more ton per year.

Head on over to the new Sustainability page to see some Google charts visualizing the miles aggregated over time. We've created two line charts: the first shows a break down of miles cycled for the current month versus the previous month, with metrics for the combined miles and miles per person; and the second chart gives a broader picture of combined miles cycled per month, starting from the beginning of the year to the present. From the latter you can see that we got off to a slower start than last year but are now putting in many more miles in cycling to work.

Cycling to work has been wonderful for Robert and me. Some of the benefits:

It's a great way to start the morning and to reduce stress at the end of a work day.
In Durham odds are you'll get to use the American Tobacco Trail for part of your commute, which means you'll get to see all kinds of interesting and beautiful wildlife in your morning and afternoon commute - we've seen turtles, hawks, foxes and fox cubs, and beavers, among other creatures.
The health benefits are well-documented – check out this neat infographic for a breakdown.
It's a meaningful way to reduce our carbon footprint and take cars off the road. With atmospheric concentrations of CO² recently surpassing 400 parts per million, it's time for everyone to get real about reducing emissions and thinking about how to contribute to a solution - and bicycle commuting is a great way to do that.
As a bonus, you can spend more time with your pets by bringing them along for the ride! Check out these photos of Robert's dog sitting pretty after the commute this morning.

We hope this inspires you to hop on a bicycle and ride to work!

bicycle commuting

Sustainability

Google + button hover and Zen 5.x

Frank Yonnetti — Fri, 04 Jan 2013 02:02:08 +0000

A problem with the recommendations hover

After adding the Google + button to our blog and news pages, I notice a display issue with the recommendations hover drop-down. It appeared to be slightly blown apart at the top, but how do I figure out what is causing this?

The problem found

Well, after spending some time reviewing the generated code, using firebug, I begun to think it wasn't Google's CSS causing the issue. So I searched through the Drupal core and Zen theme CSS and by process of elimination found the culprit. It was the normailize.css(scss) file in our Zen subtheme. It contained the responsive image declaration that was overridding the inline <img> height value.

img {
  /* Responsive images */
  max-width: 100%;
  height: auto;
}

One possible, but maybe not ideal, Fix

So how do you override, or disable, height:auto? That's a good question, because "auto" is the default setting for height. So the best solution I could come up with to override the CSS was by adding a fixed css height value for each image used. But what happens when Google changes the output… guess I'll have to fix again?

.pls-topLeft img,
.pls-topTail img.pls-spacerbottom,
.pls-topRight img,
.pls-contentLeft img.pls-spacerright,
.pls-dropRight img.pls-spacerleft,
.pls-bottomLeft img,
.pls-dropBottom img.ls-spacertop {
  height: 1px;
}
 
.pls-vertShimLeft img,
.pls-vertShim img,
.pls-vertShimRight img.pls-dropTR {
  height: 4px;
}
 
.pls-vert img.pls-dropBL,
.pls-vert img.pls-dropBR {
  height: 5px;
}
     
.pls-topTail img.pls-tailbottom {
  height: 9px
}
 
.pls-dropBottom img.pls-tailtop {
  height: 13px;
}
 
.pls-contentLeft img {
  height: 15px;
}
 
.pls-contentWrap img.pls-spinner,
.pls-contentWrap img.pls-tailright {
  height: 16px;
}
 
.pls-dropRight img.pls-tailleft {
  height: 19px;
}

All fixed, for now...

Drupal

Google Plus

CSS

Links for 2012-09-14 [del.icio.us]

Sat, 15 Sep 2012 00:00:00 PDT

Links for 2012-09-12 [del.icio.us]

Thu, 13 Sep 2012 00:00:00 PDT

Agustín Jiménez en El Club de la Comedia - YouTube

Links for 2012-09-11 [del.icio.us]

Wed, 12 Sep 2012 00:00:00 PDT

Help us test our contest software for a chance to win an amazon.com gift card

David Minton — Wed, 12 Sep 2012 02:45:41 +0000

Testing PunchTab, the world's first instant loyalty platform

It is often said there is no free lunch, though if you are lucky, you may get one, if you can order it from Amazon.com with a $10.00 Amazon.com gift card from Designhammer. Why the prize you may ask? We are testing out PunchTab, an online service billed as the world's first instant loyalty platform. One component of which is online contest management.

To get a feel for how PunchTab works, and to iron out any kinks before we offer up a more substantial prize (hint, hint, check back soon), we thought we would put something small on the line. Don't delay; the contest ends at 2pm on Wednesday, September 12th, 2012.

Why PunchTab? I was looking for a better (i.e. easier) way to manage our online contests, and came across a post on TechCrunch: Social Loyalty Platform PunchTab Launches Agency Platform; Touts Customers Like eBay & Arby’s. In addition to Giveaways like this one, PunchTab also manages online Loyalty Programs, as well as Badges & Achievements. There are currently three account levels with different benefits: free, $99/month, and $999/month. We are trying the free account.

We will be posting our findings once we finish the contest. If you have any feedback on your experience with PunchTab, please leave a comment, below.

Social Media

Social Networking

DesignHammer partner to be a "homeless CEO" for charity

David Minton — Tue, 04 Sep 2012 18:31:51 +0000

I need your help. I was just accepted to participate in the United Way of the Greater Triangle's CEO Sleepout, an event that has never been done here before: a leadership sleepout on the streets to draw attention to those who live in poverty. The event will take place, rain or shine, Thursday, September 6 at 6:30pm through Friday, September 7 at 8:00am, in downtown Durham.

It’s been said, “A nation’s greatness is measured by how it treats its weakest members.” In a nation as great as ours, people shouldn’t need to worry about where they will get there next meal, or if they will have a safe place to sleep at night. I hope through my participation I can help raise awareness for homelessness and poverty in our community.

This is no ordinary fundraiser; rather than sitting in a climate-controlled room, listening to a keynote speaker over coffee and dessert after a filling dinner, we will be sleeping on the street. Well, actually on the sidewalk in front of the Durham Performing Arts Center (DPAC). We will be provided bottled watter, coffee, and access to a port-a-potty. I will be able to purchase “comfort items” with the donations I raise, which include:

$250: a piece of cardboard for a CEO to sleep on — AND, a hot, nutritious meal and social call to a homebound senior for six months.
$500: a blanket for CEO on Sleepout night — AND, one week of safe shelter and support for a family as they seek to move out of homelessness.
$750: a cardboard box as shelter for a CEO — AND, mental health counseling, substance abuse treatment and help finding a job for 10 women.
$1000: a sleeping bag for a CEO — AND, a matched savings program and financial literacy assistance for teens aging out of the foster care system.

I hope you will consider pledging to support my efforts toward this worthy cause, and help me not sleep on the bare pavement. Please make sure you select my name from the “Donate on Behalf of” menu at the very bottom of the form.

Thank you for supporting the United Way of the Greater Triangle, and the effort to fight homelessness and poverty in our community.

Three notes on leadership

David Minton — Wed, 06 Jun 2012 17:50:11 +0000

Today marks the sixty-eighth anniversary of Operation Overlord, the code name for the Allied invasion of Normandy, on June sixth, 1944. The D-Day invasion was successful, and likely shortened the war.

Prior to the departure of the troops for the invasion, General Eisenhower provided the following message of encouragement to the troops:

“Order of the Day” — statement as issued to the soldiers, sailors and airmen of the Allied Expeditionary Force on June 6, 1944 [The Dwight D. Eisenhower Presidential Library and Museum]

“Soldiers, Sailors and Airmen of the Allied Expeditionary Force!

You are about to embark upon a great crusade, toward which we have striven these many months. The eyes of the world are upon you. The hopes and prayers of liberty loving people everywhere march with you. In company with our brave Allies and brothers in arms on other fronts, you will bring about the destruction of the German war machine, the elimination of Nazi tyranny over the oppressed peoples of Europe, and security for ourselves in a free world.

Your task will not be an easy one. Your enemy is well trained, well equipped and battle hardened, he will fight savagely.

But this is the year 1944! Much has happened since the Nazi triumphs of 1940-41. The United Nations have inflicted upon the Germans great defeats, in open battle, man to man. Our air offensive has seriously reduced their strength in the air and their capacity to wage war on the ground. Our home fronts have given us an overwhelming superiority in weapons and munitions of war, and placed at our disposal great reserves of trained fighting men. The tide has turned! The free men of the world are marching together to victory! I have full confidence in your courage, devotion to duty and skill in battle. We will accept nothing less than full victory!

Good Luck! And let us all beseech the blessings of Almighty God upon this great and noble undertaking.”

— Gen. Dwight D. Eisenhower

An earlier draft of the message provides us an insight into his thoughts, as he reordered parts of the message:

“Order of the Day” — draft of statement [The Dwight D. Eisenhower Presidential Library and Museum]

The General, however, had also planned for the worst. While not as well know, Eisenhower also drafted a message in case the invasion failed. On D-Day +35, Gen. Eisenhower came across the forgotten note, a piece of history likely to have been lost, had it not be saved by his naval aide, Capt. Harry C. Butcher. The note (mistakenly dated July fifth) read:

“Our landings in the Cherbourg-Havre area have failed to gain a satisfactory foothold and I have withdrawn the troops. My decision to attack at this time and place was based upon the best information available. The troops, the air and the Navy did all that Bravery and devotion to duty could do. If any blame or fault attaches to the attempt it is mine alone.”

“In Case of Failure Message” [The Dwight D. Eisenhower Presidential Library and Museum]

Had the invasion failed, another would not have been possible, based on necessary tidal conditions, moon phase, and weather, for another year. During that time, the Soviets would have driven west to Berlin, and likely to the Rhine, and possibly as far as the North Sea and English Channel, resulting in all of continental Europe behind the Iron Curtain.

As a lesson to the rest of us in leadership, Eisenhower trained and motivated his organization for success, though recognized the chance of failure. In case of failure, he was prepared to accept the ultimate responsibility.

How Abandoned Blogs and National Public Radio can help a Black Hat SEO

Stephen Pashby — Mon, 14 May 2012 14:00:12 +0000

As one of of DesignHammer’s organic Search Engine Optimization (SEO) services, we monitor our client's position on Search Engine Results Pages (SERPs), along with those of their major competitors. Recently, a competitor to one of our clients rocketed to the top of the search rankings for several of their targeted search terms. There are a number of reasons this could happen, so I set out to determine what would account for this dramatic change.

At the most basic level, organic SEO can be divided into “on page” and “off page” techniques. On Page techniques include HTML structure, and written content on a page being optimized, while Off Page techniques primarily focus on the quality and quantity of incoming links.

Since there are a number of tools that automate analysis of incoming links, that was my first path of inquiery. I quickly noted links from over ten TypePad blogs to the competitor’s website for several of their targeted search terms.

When I reviewed the TypePad blogs, I found they were obviously being used solely to create backlinks for SEO. While this was not surprising, what did surprise me was several of the blogs I reviewed had exceptionally good PageRank for a spam blog (PageRank of 4 or 5 out of a possible 10). This was unexpected since a number of recent updates to the Google algorithm were supposed to punish low quality websites such as this one.

A Spam Blog with a Page Rank of 5 on this page.

Most of the links on the blog are to product pages on e-commerce sites, a common tactic for less reputable SEO firms to improve the search performance of their client's pages. While tactics such as this can be effective in the short term, they violate Google's Webmaster Guidelines and can result in penalties for a site if it is caught benefitting from such link schemes. The most recent Google algorithm update has reportedly damaged webspam tactics such as this. If that is true, why is this link scheme still so effective?

I did some further investigation and found that one of the sites, librarianinblack.typepad.com* was linked to from National Public Radio as one of the "library blogs we love." With a PageRank of 5, a link from this NPR subpage is a high quality link (the NPR home page, with a PageRank of 8, would help even more). As I have come to expect something beyond links to spam from NPR, I decided to dig a bit deeper.

NPR: Library Blogs We Love.

After consulting the Wayback Machine (an incomplete archive of Web pages going back as far as 1996), I discovered that from 2004 through 2009 the Librarian In Black was a regularly updated, apparently well read and respected blog sharing resources and discussions for the "tech-librarians-by-default." In 2009, Librarian In Black moved off of TypePad to it's new home, librarianinblack.net.

The New Librarian In Black Blog.

However starting in 2011, librarianinblack.typepad.com* started a new life as a splog (splog = spam + blog). Splogs are not a new phenomenon, and this was a valuable one. When the actual Librarian In Black blog moved to its own domain, not every linking site updated their links. This left a URL with significant link juice to be used for spamdexing.

Site Activity: 2004-2011.

As a testament to the residual PageRank, librarianinblack.typepad.com* is still the second result in Google for a search for "librarian in black."

Search Results: Librarian in Black.

While we may never know exactly how this particular web spammer stumbled upon librarianinblack.typepad.com*, Social Engineers and Black Hat SEO practitioners are always on the lookout for new ways to claim blogs with existing page rank.

At DesignHammer, we do not practice or endorse SEO practices that violate Google's SEO Guidelines. We feel that the potential temporary benefit of these prohibited practices is outweighed by the potential for lost business and damaged reputation if caught. In short, black hat SEO practices are bad for business.

* Throughout this blog, I have refrained from linking to the spam blog. I don't see any reason to legitimize it with any of DesignHammer's link authority.

SEO

Black Hat SEO

Google

Drush Rebuild: A utility for rebuilding Drupal development environments

Kosta Harlan — Wed, 28 Mar 2012 14:04:05 +0000

Rebuilding a local development environment for a Drupal site can often be a chore - see the last post, "Workflow and tools for developing with install profiles and Drush Make", for a complex example.

In theory, you should be able to just get the code from the production or staging site onto your local machine, get a dump of the database, and off you go. drush sql-sync and drush rsync are two very powerful commands that can accomplish this for you in no time at all.

But that's usually not enough to get your dev environment up to date, because then you need to disable Google Analytics, CSS/JS aggregation, caching, and enable the Devel module, etc.

Further, each site might have its own set of modules that need to have settings adjusted. For example, the Salesforce module should connect to a Sandbox, not the production instance, when it's enabled on the local development environment.

To make things more complicated, each site can have a different structure. Here at DesignHammer, we have sites built using Drush Make, sites where the entire codebase is in Git, others where the codebase is in SVN, and still others where only our custom code is in the repository, and we symlink to a Drupal directory.

Once you go through all of the steps of rebuilding your dev environment, then each co-worker needs to go through the same tedious process. Depending on the complexity of the site, this can take quite a while. If you stop development on a site for a couple months, you find you've forgotten half the steps and need to go through the whole process again.

How can we get rid of repetitive and tedious tasks in rebuilding a local development environment and make this process simpler?

Drush Rebuild

I wrote a simple utility, Drush Rebuild, to help me manage the process of rebuilding a local development environment. Drush Rebuild doesn’t make assumptions about your repository structure (Drush Make, entire codebase in repo, etc), nor does it care about extra steps you need to take when configuring a development environment, like disabling caching, adjusting connections with 3rd party services, and so on.

Instead, the utility provides a framework for executing rebuild scripts for a given site, using the power of Drush aliases and the drush php-script command.

How does Drush Rebuild work?

Download the Drush Rebuild extension to your ~/.drush directory. In your terminal, type drush help rebuild to test that installation succeeded and to get an overview of the options.

Edit your local dev site alias (run drush topic docs-aliases if you are not familiar with aliases), and add an entry under the path-aliases array for %local-tasks. It should look something like this:

$aliases['dev'] = array(
  'root' => '/path/to/site',
  'path-aliases' => array(
    '%local-tasks' => '/path/to/local-tasks-dir',
  ),
  'rebuild' => array(
     'drupal_5_site_root' => '/path/to/drupal5/siteroot',
    'git_repo' => '/path/to/site/repo',
  ),
);

Note the rebuild array in the alias, which can be used to store paths or values specific to your site rebuild script.

In your local tasks directory, create a file called tasks.php. This where you implement the logic specific to a given site rebuild so that when you run drush rebuild @mysite.dev, the tasks.php file in local tasks is executed.

This means that you can create rebuild task scripts for your different sites, yet have a single mechanism to trigger a rebuild: drush rebuild @mysite.dev.

Your themer or site builder doesn’t have to know about drush rsync or drush sql-sync, or the 20 steps you would take to change module and theme settings, they can just run the rebuild command and have a working local development environment up and running. You can save your rebuild script in the repository so six months from now, you don't have to dig through notes or try to remember the steps you took to set up an environment, you can simply run the command and be ready to go.

Here is an example script to demonstrate some of what you can do: [gist:2219387]

One nice thing about this approach is that the tasks.php file can exist in your site's version control, while the database and paths specific to a given developers environment are defined in the drush alias.

If you don't like drush scripts, your tasks.php file can call bash scripts, or anything else for that matter.

By default, Drush Rebuild will create a backup of your environment by using Drush 5’s archive-dump command, so if your rebuild fails, you can restore your previous environment. You can also pass the --view-script option to have a look at the rebuild script before you run it, which is good to refresh your memory on the particulars of the local environment and how it might differ from your staging or production site.

That's all there is to say about Drush Rebuild for now. It's a small utility and its scope is modest, but I think it will help our team save a lot of time. Please try it out, let me know if you find it useful, and if you have additional example scripts or functionality to add to the project, please post them in the issue queue.

Workflow and tools for developing with install profiles and Drush Make

Kosta Harlan — Thu, 01 Mar 2012 16:23:24 +0000

A few months ago we completed a Drupal 5 to Drupal 7 migration project for a North Carolina museum website. Actually the Drupal 5 site was more of a Frankenstein site; the previous developers had more or less built their own CMS on top of Drupal. Fortunately, the superb Migrate module made writing migration code for this project a snap.

Getting a workflow together, however, was a bit more of a challenge. We had four people working on the project: two developers, a site builder, and a themer.

Because the project was complex and contained a number of different components, we agreed that development would work best with each developer building aspects of the site on their local machine. That way my work in writing migration code would not interfere with our themer's work, nor would it bother someone working on site building.

The key ingredients to a local development first workflow are git, drush, drush_make (now included in Drush 5), installation profiles, and Features.

In this blog post, we'll review some of the workflow and tools we used for development. We'll use a fictitous "MySite" project for our example.

Workflow

Install Profile

The file mysite.profile contains the default settings for the MySite project. It defines the content types, user roles, permissions, etc that go into a default Drupal install.

Unlike Drupal 6, the Install Profile in Drupal 7 is actually a few files: mysite.profile, mysite.info, mysite.install.

Drush Make files

There are actually two drush make files: mysite.build and mysite.make .

mysite.build is brief:

core = 7.x
api = 2
projects[drupal][type] = "core"
; Our distribution
projects[mysite][type] = "profile"
projects[mysite][download][type] = "git"
projects[mysite][download][url] = "git@gitserver.com:mysite.git"
projects[mysite][download][branch] = "develop"

mysite.make contains the list of modules, themes, and libraries to download and add to the site.

Features

Features will be built to separate content from presentation. For example, if you want to export your work for "Blog functionality", one feature would contain the content type and fields, while a separate feature would contain the Views for displaying it on the site.

Git

The git repo for MySite is the basic structure for the site. The structure for the repo should not be altered, otherwise drush make won't work properly with it.

The repo looks like this:

/mysite (root of git repo)
/mysite/modules/contrib
/mysite/modules/custom
/mysite/themes/
/mysite.build
/mysite.make
/mysite.profile
/mysite.info
/mysite.install
/resources
/README.md

As you build your features, drop them into /path/to/repo/modules/custom/[name-of-your-feature]
Custom themes go in /path/to/repo/themes/[name-of-theme]
Custom modules go in /path/to/repo/modules/custom/[name-of-module]
Edits to the install profile go in /path/to/repo/mysite.profile
Enable modules in /path/to/repo/mysite.info

The Drupal 5 site is in a separate repo.

Example workflow

Let's say you want to add Webform functionality to the latest dev build. You enable the Webform module in Drupal and configure the settings to your liking.

Using Features, you then package up the relevant settings and configuration into your mysite_webform Feature and download it to /path/to/repo/modules/custom/mysite_webform.

In the mysite.info file, you would add your Feature to the list of dependencies (this will enable it on site install).

Using git, you would then add this directory and mysite.info, commit to develop, and push the code up to origin.

Then other developers can run through the site rebuild command(s) and have your Webform feature enabled and configured locally.

Tools to make development easier

Our team's comfort with using the command line or drush varies. For a local development first workflow, using the command line is essential to productive, time-efficient development. Even for those of us more comfortable with the command line and drush commands, remembering all the commands to rebuild our local environments is a challenge. So, we wrote some scripts to help with the proces.

Rebuilding the site

The main script is called rebuild.sh. By running rebuild.sh on your local machine, you can ensure that you will have (1) the latest code from the develop branch in origin, (2) your local site's database will be identical to the other developers, (3) the migration script will pull in the latest content from the source database. So, let's break it down:

The first part is a simple yes/no prompt (borrowed from the Aegir project). This makes it simple for us to ask the user if we should continue at different points throughout the rebuild process:

prompt_yes_no() {
  while true ; do
    printf "$* [Y/n] "
    read answer
    if [ -z "$answer" ] ; then
      return 0
    fi
    case $answer in
      [Yy]|[Yy][Ee][Ss])
        return 0
        ;;
      [Nn]|[Nn][Oo])
        return 1
        ;;
      *)
        echo "Please answer yes or no"
        ;;
    esac
 done
}

The next step in rebuild.sh is to read the developers configuration from rebuild.config. This file should sit in the same directory as rebuild.sh (in our case, we kept both in the /resources directory at the root of the repository), and rebuild.config should not be tracked in the repo (a rebuild.config.example file should be though, as a helpful example to the other developers):

# Reading options from rebuild.config
FILENAME=rebuild.config
while read option
do
    export $option
done < $FILENAME
DRUSH="$DRUSH_PATH"
 
# Start our rebuilding
clear
 
cat <<EOF
 
*** IMPORTANT ***
 
The following values were read from rebuild.config in your resources directory.
Please make sure they are correct before proceeding:
 
  D5_DRUPAL_ROOT = $D5_DRUPAL_ROOT
  D7_DRUPAL_ROOT = $D7_DRUPAL_ROOT
  DRUSH_PATH = $DRUSH_PATH
  D7_DATABASE = $D7_DATABASE
  D5_DATABASE = $D5_DATABASE
  D5_GIT_REPO = $D5_GIT_REPO
  D7_GIT_REPO = $D7_GIT_REPO
 
EOF
 
if ! prompt_yes_no "Are you sure you want to proceed?" ; then
    exit 1
fi

Basically, this is reading some variables that we can use later on the script. If we look at what is in rebuild.conf, we see:

[gist:1935141:rebuild.conf]

The script asks that we do indeed want to rebuild our local environment, and continues by removing the old directory, running Drush Make, and re-installing the site using our install profile.

echo 'Rebuilding MySite...'
echo 'Removing '$D7_DRUPAL_ROOT' directory...'
chmod a+w $D7_DRUPAL_ROOT"/sites/default"
chmod a+w $D7_DRUPAL_ROOT"/sites/default/files"
rm -rf $D7_DRUPAL_ROOT
echo 'Executing drush make'
$DRUSH make --prepare-install --force-complete $D7_GIT_REPO"/mysite.build" $D7_DRUPAL_ROOT -y
cd $D7_DRUPAL_ROOT
echo 'Re-installing site database'
$DRUSH si mysite --site-name="MySite" --db-url="mysql://root:root@localhost/$D7_DATABASE" -y
echo 'Finished rebuilding directory and re-installing site.'

On a large project (75+ contributed modules), Drush Make and a Site Install could take about 5 minutes. If you use Squid as a caching server for drush module downloads, however, the process takes only about one minute. You can also experiment with providing a "file:///" URL in your mysite.build file for the [download][url] section where you are specifying the location of the make file.

Next up, we create some symlinks from the git repo to our site build directory:

cat <<EOF
 
Would you like to have symlinks set up? The script will create symlinks as
follows:
  ln -s $D7_GIT_REPO/modules/custom $D7_DRUPAL_ROOT/profiles/mysite/modules/custom
  ln -s $D7_GIT_REPO/themes/mysite $D7_DRUPAL_ROOT/profiles/mysite/themes/mysitetheme
 
EOF
 
if ! prompt_yes_no 'Create symlinks?' ; then
    exit 1
fi
 
echo 'Creating symlinks'
cd $D7_DRUPAL_ROOT
rm -rf profiles/mysite/modules/custom
rm -rf profiles/mysite/themes/mysitetheme
ln -s $D7_GIT_REPO"/modules/custom" $D7_DRUPAL_ROOT"/profiles/mysite/modules/custom"
ln -s $D7_GIT_REPO"/themes/mysite" $D7_DRUPAL_ROOT"/profiles/mysite/themes/mysitetheme"
echo 'Done making symlinks.'

We continue on and migrate content, if desired. Sometimes it's helpful to rebuild the local site without migrating any content, for example, if you want to alter a field, you need to do that before any content has been added to it.

# Content migration
cat <<EOF
 
The script will run 'drush migrate-import --all', which will run all
content migration patterns. You must have the Drupal 5 site setup locally
for this to work properly.
 
EOF
 
if ! prompt_yes_no "Migrate content and files?" ; then
    exit 1
fi
 
echo 'Migrating database content...'
echo 'Updating Drupal 5 git repo...'
cd $D5_GIT_REPO
git checkout master
git pull
# TODO: Set this so it imports only if git pull brought us new content
echo 'Importing Drupal 5 database...'
mysql -uroot -proot $D5_DATABASE < $D5_GIT_REPO"/database/mysite-production.sql"

As you can see, we were storing the D5 database in a git repo. Normally I would never put a database in a git repo, but because not all developers had access to the production server running the Drupal 5 site, we decided to store an ordered dump, excluding data from a number of cache tables. We wrote a script for this too; the script takes a snapshot of the D5 database, overwrites the mysite-d5-production.sql file stored in the D5 git repo, commits it to the master branch, and pushes to origin.

[gist:19035141:db_update.sh]

Ok, back to the rebuild.sh script! Next we do a couple of set up tasks for the Drupal site:

cd $D7_DRUPAL_ROOT
 
echo 'Setting date and timezone settings...'
$DRUSH vset date_first_day 1 -y
$DRUSH vset date_default_timezone 'America/New_York' -y
$DRUSH vset date_api_use_iso8601 0 -y
$DRUSH vset site_default_country 'US' -y
$DRUSH vset configurable_timezones 0 -y
$DRUSH vset user_default_timezone 0 -y
echo 'Done.'
# Run cron to make sure any initialization necessary in Drupal takes place before
# nodes are imported.
echo 'Running cron...'
$DRUSH cron

We had trouble setting some of these variables in the install profile, so we placed them in this script and had no troubles with this method.

Then, we run the migrations:

# Migrate isn't resolving dependencies correctly so we specify the migration order here manually
$DRUSH mi mysiteUser
$DRUSH mi mysiteBlocks
$DRUSH mi mysiteNewsNode
$DRUSH mi mysitePageNode
$DRUSH mi mysiteStaffMemberNode
$DRUSH mi mysiteFinish
 
echo 'Done.'

Then we enable our Webform feature:

# The Webform feature, which contains Webform nodes, is enabled after 
# all other features so as to not interfere with node IDs that are preserved
# from the Drupal 5 site
echo 'Enabling our Webforms'
$DRUSH en mysite_webforms -y

Finally we make sure the Drupal 7 site has all the files from Drupal 5:

# File migration
 
echo 'Copying files...'
mkdir $D7_DRUPAL_ROOT"/sites/default/files/files"
cp -Rp $D5_DRUPAL_ROOT"/files/"* $D7_DRUPAL_ROOT"/sites/default/files/files/"
echo 'Done.'
echo 'Copying images...'
mkdir $D7_DRUPAL_ROOT"/sites/default/files/images"
cp -Rp $D5_DRUPAL_ROOT"/images/"* $D7_DRUPAL_ROOT"/sites/default/files/images/"
echo 'Done.'
echo 'Finished content migration!'
 
echo 'Rebuild completed.'

End result, after running rebuild.sh I have a complete site build that is identical to the other developers, symlinks are set up, content is migrated, and I am ready to start working on features or bug fixes. When I'm done with my work, I can merge into develop and push my changes up to origin, and now every other developer can have my changes in their local environment.

Verifying make files and install profiles

One problem that cropped up a few times as we were using this workflow were commits that broke the build. For example, if someone added a module incorrectly to the mysite.make file, and added the module as a dependency in mysite.info, the build would break because Drupal would try to enable a module that actually hadn't been downloaded in the site build. So, we wrote two simple scripts, verify_install.sh and verify_makefile.sh. As their filenames suggest, the scripts allow a developer to check a makefile or an install profile before they commit to the repository.

Other tools?

So, that's the basic workflow and toolset we worked with for a larger migration project using an install profile and drush make. We'd love to hear from you if you used other tools or a different workflow.

If we did this project again, one thing I'd probably skip is the use of drush make - better just to track the entire site in a git repo. I would probably also take the time to package up these scripts as a few drush commands that made use of drush aliases, adding a line in the drush alias to specify the git repo.

Hopefully these scripts will be useful to others who are undertaking projects like this. Feel free to leave a question below!

How to relocate modules and themes from a Drupal Install Profile

Kosta Harlan — Fri, 24 Feb 2012 17:36:48 +0000

At DesignHammer we frequently use Install Profiles for migration projects. An install profile makes it easy for developers to work on migration code, site builders to add and configure modules while exporting the settings to Features, and themers to work on the Drupal 7 site theme – all at the same time, without getting in each other's way.

For example, in working on migration of content, it is sometimes quite useful to tear down the site, rebuild it, and re-run the migration scripts:

drush @mysitealias.local site-install my_profile -y
You are about to DROP all tables in your 'mysite' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a few seconds ...
Installation complete.  User name: admin  User password: topsecret
drush mi --all

I don't want that to interfere with other people's work; that's why having a site that can be quickly torn down and rebuilt from an install profile and Features is quite useful.

Eventually, that usefulness runs its course. The migration scripts are completed, the site builders have added most modules and configured content types, the theme is mostly done. At this point, we need to do some more in depth testing, and edit content or create new content before deployment. So, we stop using the install profile and the site build/rebuild process.

Depending on the client, it may be fine to leave the modules and themes residing in /profiles/my_profile/. In other cases, it might be desirable to adopt a more traditional Drupal site structure and place the modules and themes in sites/all/modules and sites/all/themes.

However, you can't just move the modules and themes to a different directory, because Drupal won't know where they've gone to. You could disable, uninstall, and re-install each and every module and theme but that would be quite tedious. Instead you can do this in a couple minutes with some SQL queries. It's a good idea to run this in your local development environment before trying it out on the development site that you are collaborating with others on.

The first step is to move the modules and themes. Make sure you double check the paths to match your desired configuration (for example, you may not care about separating modules into custom and contrib directories):

[gist:1894250:relocate.sh]

(Note: other developers may have topic branches open that branched off develop before you relocated everything to sites/all/modules. If you are tracking the entire codebase in git, these developers will need to checkout their topic branch and run git rebase develop, assuming that you committed module and theme relocation work to develop.)

Next step is to tell Drupal where to find the modules and themes by executing these SQL queries, again taking care to check that the directories match the mv operations you just performaed:

[gist:2855108:relocate.sql]

Make sure that you update your site-specific drushrc.php, if it exists, to reflect the new location for downloading modules. with drush.

[gist:1894250:old-drushrc.php]

Should become:

[gist:1894250:drushrc.php]

For good measure, run drush cc all.

Now you can visit your site, and it should be working fine. "Admin > Reports > Status" will still show the name of your install profile (which is correct - that is the initial profile used to build the site), but otherwise, you've moved away from the Install Profile and can place modules and themes in sites/all/ without any issues.

Drupal Planet

Install Profile

Drupal

Links for 2012-02-17 [del.icio.us]

Sat, 18 Feb 2012 00:00:00 PST

13 Super Startups to Watch - 'Net Features - Website Magazine
The Web world moves at a furious pace, and digital workers can miss the next big thing in the blink of an eye. Some emerging services such as Pinterest are fortunate enough to take center stage while other solutions of seemingly equal value to Web pros wallow in relative obscurity.

New Year's SEO Resolutions

Stephen Pashby — Mon, 23 Jan 2012 17:48:57 +0000

A new year is a great time to break out of old habits and establish new ones. At the January meeting of the DesignHammer hosted RTP Search Engine Optimization Meetup, the group discussed our resolutions for improving our search engine optimization efforts in 2012. Here are some of our top resolutions.

Create Content

Creating interesting, well-written, and original content (sometimes referred to as linkbaiting) is one of the most widely recommended practices for increasing site traffic. As incoming links are widely believed to be one of the most important contributing factors to a site’s search performance, any content that is likely to be linked to is valuable.

Understanding the value of creating quality content is only half of the battle. The real challenge is carving out time in a busy schedule to regularly create new content that others will want to read and share. A modest goal of creating one quality blog entry a month is a good starting point.

Share Interesting Content

Just pushing your own content via your social media channels may result in your followers seeing everything you share as an advertisement. A better strategy is sharing content that your followers may find interesting, often because you find it interesting. Read about creating sharable content.

Content creation is good. Sharing quality content of your own and others is better. Speaking of sharing interesting content, here is an infographic about sharing interesting content.

Continue SEO Education

As search engine algorithms change, SEO practices must adapt. Fortunately the SEO professional is not alone in confronting these changes. Staying up to date with recent SEO developments such as Google Analytics's exclusion of logged in users' keyword searches.

Some sites we read at DesignHammer:

Structure your websites with SEO in mind

Sticking to the above resolutions will not deliver their best possible results if your own website’s structure works against you. Most modern websites are powered by content management systems (CMS) such as WordPress.

A CMS can make it simple to create new content, but most CMSs are not initially set up to support SEO efforts. For WordPress, take a look at our guide to using the All in One SEO Pack for WordPress.

SEO

WordPress

Links for 2011-09-20 [del.icio.us]

Wed, 21 Sep 2011 00:00:00 PDT

The Periodic Table Of SEO Ranking Factors
A guide, in the form of the periodic table of elements, that summarizes the major factors to focus on for search engine ranking success.
2011 Search Engine Ranking Factors
SEOmoz has compiled the aggregated opinions of dozens of the world's best and brightest search marketers into this biennial, ranking factors document. This year, for the first time, they are presenting a second form of data - correlation-based analysis - alongside the opinions of the 132-person panel.
InfoGraphics by Visual.ly
Infographics are popping up everywhere on the web, and now, if you have a data set, you can make your own infographic. San Francisco-based Visual.ly, which offers a free platform for creating infographics from data, has launched its beta version and is open to the public.
Local Search Ranking Factors
A guide to optimizing for Google Local Search results.
10 Commandments of Business Blogging
Useful guidelines for operating a blog for your business, or your employer.

Links for 2011-09-19 [del.icio.us]

Tue, 20 Sep 2011 00:00:00 PDT

The Periodic Table Of SEO Ranking Factors
A guide, in the form of the periodic table of elements, that summarizes the major factors to focus on for search engine ranking success.
InfoGraphics by Visual.ly
Infographics are popping up everywhere on the web, and now, if you have a data set, you can make your own infographic. San Francisco-based Visual.ly, which offers a free platform for creating infographics from data, has launched its beta version and is open to the public.
2011 Search Engine Ranking Factors
SEOmoz has compiled the aggregated opinions of dozens of the world's best and brightest search marketers into this biennial, ranking factors document. This year, for the first time, they are presenting a second form of data - correlation-based analysis - alongside the opinions of the 132-person panel.
Local Search Ranking Factors
A guide to optimizing for Google Local Search results.
10 Commandments of Business Blogging
Useful guidelines for operating a blog for your business, or your employer.

Links for 2011-07-14 [del.icio.us]

Fri, 15 Jul 2011 00:00:00 PDT

InfoGraphics by Visual.ly
Infographics are popping up everywhere on the web, and now, if you have a data set, you can make your own infographic. San Francisco-based Visual.ly, which offers a free platform for creating infographics from data, has launched its beta version and is open to the public.