SoundPost Media

Drupal PCI Compliance White Paper—Officially Released!

2013-07-23T07:26:00+00:00

Quick links:

Download the white paper.
Visit the Drupal PCI compliance white paper website.
View the press release.

Seven months ago I posted a lengthy article regarding PCI Compliance for Drupal. It was an MVP of sorts (Minimum Viable Post). The goal was to test the waters to see if I could gain enough interest and support to justify spending the time to create a white paper to help bring clarity to a complex and misunderstood topic. 2000+ page views and 20+ comments later, I knew that I struck a chord with enough people to take the leap, and so here we are today with a delivered contribution back to the community.

Why should you care?

Every eCommerce website that accepts credit or debit card transactions has a contractual obligation to become and remain PCI compliant (with fines and penalties if you're not compliant if a security breach occurs). And while Drupal makes it trivial to spin up a basic eCommerce website, anecdotal evidence suggested that only a subset of the community was even aware of this requirement. A smaller subset of that recognized that it was a problem. And finally, an even smaller subset knew what to do in order to become compliant. Therefore, I believed we were facing three problems:

A lack of awareness (of the requirements themselves).
A lack of acknowledgement (of the importance of compliance).
A lack of guidance (specific to Drupal community on how to meet the requirements).

In fact, I personally experienced all three stages. I had operated a Drupal eCommerce website for almost 2 years without knowing even the most basic fundamentals regarding PCI compliance. When the reality finally hit me, I was stressed to the max trying to figure this all out on my own because there were very few resources within the community. My hope is that this white paper is the very thing would have prevented me from getting into that mess into the first place!

Solving the Problems

Addressing the three problems was no easy task. If the paper was too technical, it would only be understood by developers and website owners would remain in the dark. However, making it too long and all encompassing would create a high barrier to entry with respect to people reading and understanding it. So we had to start off with some basic objectives:

Readable: It should be easily understood by Drupal developers, shops, and evaluators.
Multiple Formats: It should be available in a printable pdf as well as markdown for easy inclusion into Drupal modules.
Free: In order to get it into as many hands as possible, there should be no barrier to obtain it.
Short: A person should be able to read the entire paper is less than an hour (preferably less than 30 minutes).
Credible: The paper should be as accurate as possible in the information presented.

We believe we've hit all of these goals. We sent the paper out to numerous reviewers (technical and otherwise) to make sure the information was not overly difficult to read. We created the document in markdown and provided instructions on conversion to markdown and pdf. We hosted the document on a public github repo and public facing website where anyone can download the report for free. We almost kept the document to 15 pages (20 pages isn't too bad!)

With respect to credibility, I was fortunate enough to enlist the help of two amazing co-authors: Greg Knaddison and Ned McClain. Greg is the Drupal Security team lead and author of Cracking Drupal. Ned is the co-owner and co-founder of AppliedTrust, a company that has extensive knowledge in both Drupal and security standards, such as PCI and HIPAA compliance. Both brought a tremendous amount of experience and domain knowledge that was critical in improving the accuracy or the report.

Given all that, I believe we achieved the goals we set out for and that this white paper will be a valuable resource to the Drupal eCommerce community.

On Contributing

I started becoming active in the Drupal Community after being inspired by a DrupalCamp Colorado presentation by webchick in 2011 about the importance of giving back to the community. After that point, I definitely tried as best I could: I was active in the issue queues, I was attending meetups, and I was helping mentor new members of the community. However, I never felt like I was able to contribute something back of significance that compared to the Dave Reid's of the community (I mean the guy maintains over 50 modules!)

This project was very different. It was the first time where I felt I could contribute something back to the community that was unique. And while it has been a long, hard road, it has been both personally and professionally rewarding to see the impact it's already had on those that have read it. Needless to say, I'm excited to find the next Drupal project to continue contributing back to the community!

Comparing PCI Compliance Considerations Among Ubercart and Drupal Commerce Payment Gateways

2013-06-14T00:00:00+00:00

Selecting an appropriate payment gateway is one of the most important choices to make when designing, building, and maintaining an eCommerce website powered by Drupal. Choose poorly and the out-of-the-box feature set may not fit all of the project's needs (e.g. "where's the recurring billing option?") or may not be possible at all (e.g. "where can I charge my customer's card for a future purchase?"). The payment gateway choice will also greatly impact the resources required (in terms of time, money, and expertise) to sufficiently secure the credit card transactions in order to achieve and maintain PCI compliance.

As a Drupal developer trying to wow clients with amazing out-of-the-box features, it can be tempting to focus on functionality over security. However, one of my biggest concerns for those selecting Ubercart as their eCommerce solution is its lack of available payment gateways that can achieve a clients desired feature set while still being able to reduce one's PCI compliance woes. The goal of this article is to encourage everyone to select a shared-management gateway solution (defined and described below) and to highlight that Drupal Commerce has more of these types of gateways available.

Payment Gateway Types

The Payment Card Industry (PCI) groups payment gateways into three basic types: merchant-managed, shared-management, and wholly outsourced. I'll explain each of them in reverse order.

Wholly Outsourced

In this implementation, the eCommerce platform is entirely hosted, managed, and secured by a 3rd party vendor that explicitly assumes the PCI responsibilities to secure the credit card payment process. Examples include: Bigcommerce, Volusions, etc. The only Drupal specific example I know of that that could fit this criteria would be Drupal Gardens using Cashie or Paypal.

Shared-management

In this implementation, the shopping cart experience begins on a Drupal site and the credit card payment is submitted directly to the payment gateway by one of three types of methods:

Hosted Payment Page (HPP). This involves redirecting a customer to your payment processor's website where they enter their payment information directly on the payment gateway's servers. Once the transaction is successful, the customer is redirected back to the Drupal site to an order confirmation page with an authorization code so that Drupal knows the payment went through.
Direct Post. This is essentially a slight of hand in which the credit card form on a Drupal site is modified such the credit card details are posted (through an HTML post over HTTPS) directly to the payment processor instead of being submitting to the Drupal Form API . Once the payment is approved, the payment gateway sends a one-time verification token back to the customer, which is then processed through Drupal Form API and sent back to the payment gateway. The token is used simply so that Drupal can verify that the payment was accepted.
iFrame. This is essentially a combination of the above two methods. Here the credit card form is embedded on the checkout pane through an iframe. Therefore the form, being hosted on the payment processor's server, receives the credit card data directly and returns a token that can then processed through Drupal to charge and/or verify a payment with the payment gateway.

Merchant-Managed

In a merchant-managed implementation, the credit card information is submitted directly back to a Drupal site through the form API. Drupal then processes and transmits the card data to the payment processor and receives a response code to let it know where the payment succeeded or failed.

PCI Compliance Considerations

Choosing a merchant-managed solution is the most risky because you assume more of the responsibility and liability in securing the entire credit card transaction process. Choosing a wholly outsourced solution is perhaps the most restrictive because you essentially lose all the benefits of using a flexible and feature rich CMS like Drupal.

Shared-management solutions are the balance point between these two extremes. They allow one to leverage most of the flexibility and functionality of Drupal while significantly reducing the amount of time, effort, and resources required to achieve and maintain PCI compliance.

Comparing Ubercart and Drupal Commerce Payment Gateways

At first I wanted to create an exhaustive list of every payment gateway, but I decided to focus on a subset to simply illustrate the point. If I have neglected any gateways that would paint a different picture, please be sure to alert me in the comments section and I will correct these tables.

Here a the breakdown of several payment gateway options for Drupal Commerce:

Gateway	Merchant Managed	Direct Post	HPP	iframe
Authorize.net ARB	X
Authorize.net CIM	X
Authorize.net DPM/SIM		X	X
Authorize.net Hosted CIM				NA
Braintree		X
Hosted PCI				X
Paypal WPS			X
Paypal PPA			X	X
Stripe		X

And here is a similar breakdown for Ubercart.

Gateway	Merchant Managed	Direct Post	HPP	iframe
Authorize.net ARB	X
Authorize.net CIM	X
Authorize.net DPM/SIM		X	X
Authorize.net Hosted CIM				NA
Braintree		NA
Hosted PCI				NA
Paypal WPS			X
Stripe		NA

Sadly almost every (available) shared-management implementation for Ubercart involves a redirect to a hosted page, which clients in the United States are usually resistant towards because they dislike not being able to keep the client on site during the entire checkout process (sidenote: citizens of the EU tend to be much more accepting of hosted payment pages, so this stigma against HPP's is not necessarily going to persist). Thankfully there is at least one known direct post method (Authorize.net DPM) for Ubercart, but this option cannot be used in conjunction with card on file or recurring billing capabilities. As for including iframe implementations, such as Authorize.net Hosted CIM, it's already been ruled out as unlikely to happen for Ubercart.

By comparison, Drupal Commerce has several different options with respect to companies offering shared-management implementation (Stripe, Braintree, Hosted PCI) and actually offers an iframe option (Hosted PCI). The Drupal Commerce community is also very active and growing while Ubercart's community will likely hit end-of-life in the next year.

Author's Note: I know there are many many more Ubercart payment gateway modules out there, but many of them are deprecated, have fewer than 50 users, and/or are unmaintained.

Summary

Selecting the right payment gateway is not a decision that should be made lightly.
Shared-management gateways tend to offer the best balance of features and ease of achieving/maintaining PCI compliance.
Drupal Commerce offers more shared-managment solutions, both in terms of the quantity of companies to select from as well as the diversity in the types of implementations.

To learn more, please read my previous article (Let's Talk About PCI Compliance for Ubercart and Drupal Commerce) and stay tuned for the PCI compliance white paper that should be ready in a few short weeks!

Drupal PCI Compliance White Paper: Update 5/5/2013

2013-05-07T01:00:00+00:00

For context, click here to jump down to the reference links.

Where We Are

I'm pleased to announce the following:

My co-authors and I have completed a rough draft of this white paper and we're actively refining it to get to a completed first draft.
Ned McClain of Applied Trust has joined the project as a co-author. Ned's expertise and years of experience in this field has been an extremely valuable asset and this project will continue to benefit as a direct result of his input.
A heartfelt thanks to Ryan Cross of CrossFunctional for becoming our latest project sponsor.
The article that sparked this project (Let's Talk About PCI Compliance for Ubercart and Drupal Commerce) has crossed 2500 page views. This reinforces (at least to me) that there is a demand for more information on this subject matter.

Why PCI Compliance for Drupal Is More Important Than Ever

The number of reported Ubercart/Drupal Commerce installations continues to grow rapidly.
Many "silver bullet" strategies are not as bulletproof as you'd like to believe.
A new version of the PCI standard will be released within a year and the requirements are only going to get more stringent.
As companies become more distributed and adopt cloud-based solutions, it's important to define who is responsible (and liable) in the context of securing payments.
Fully understanding this topic can give you and/or your business a competitive advantage in the Drupal ecommerce marketplace.

And perhaps the most important item—if you currently own, operate, or host an ecommerce website that is NOT compliant, you could be putting your business at risk.

Next Steps

This is a complex topic that requires a lot of time to check assumptions, distill a large volume of material down to the most important elements, and write it in a way that is understandable across several audiences within the community. Having nearly achieved a fully complete first draft, we are at the stage where we will need to iterate and refine it to ensure its one cohesive document and it has all the necessary components (most notably references, citations, and footnotes). We will then reach out to additional reviewers to get feedback from a wider audience. If all goes as planned, this feedback will only require us to make minor adjustments and we will have a clear path forward to a final release.

Sponsorship

There are still several gold and silver sponsorships available if you are willing and able to fund the remaining portions of this project. While a lot of progress has been made, I recall several personal (and painful) experiences submitting manuscripts to scientific journals only to find out that the quantity of revisions requested required rewriting a paper from scratch. Yes this can be disheartening, but it almost always resulted in a much better end product. Therefore, if you would like to become a sponsor, please reach out to me using the contact information at the official website for the white paper.

Thank you for your time and I look forward to contributing this work back to the community!

Reference

The following articles, posts, and websites describe the motivating factors for starting this project:

Proposal: Drupal PCI Compliance White Paper

2013-01-28T20:25:00+00:00

UPDATE: A white paper on Drupal PCI compliance is actively being worked on. Please visit the official website for more details.

In refererence to the loss of undocumented wisdom, Andrew Carnegie once stated that “it was one of the sins of the ages that this knowledge, gained at such a tremendous price, by so many men, was buried with their bones when they died. Nobody had ever organized it into a philosophy and made it available to the man of the street.”

I feel the exact same way when I think about the number Drupal developers that have suffered through the long, hard journey of achieving and maintaining PCI compliance for ecommerce websites. With over 67,000+ active Ubercart and Drupal Commerce websites (as reported by Drupal.org), one might assume there would be an abundance of quality resources out there (articles, blog posts, youtube videos, etc) to help others speed through this torturous learning curve.

Unfortunately, I didn't believe such a resource existed that was specifically tailored to the Drupal community. This inspired me to write a somehwat lengthy article to start that conversation. It touched on a lot of the major pain points, provided the pros and cons of each solution, and it also contained an aggregated list of resources that I had found over the last several years. The feedback was incredible. It had clearly struck a chord with a lot of developers and sparked a conversation.

The Next Step

In that article I had pitched the idea of taking it a step further and creating a white paper that was similar in form the Drupal Security Report. My intention was to go beyond a simple article and create something more definitive. I want to create a quality document that any developer or evaluator could read in a single sitting and get a solid high level overview of the issues at hand. And if it helps the next 67,000+ Drupal e-commerce sites achieve and maintain their PCI compliance, I’ll consider this a huge success!

The Proposal

Without further ado, you can access the proposal document here, which is the domain that will ultimately host this document as well as any future versions. My goal is to have this completed sometime before DrupalCon Portland, where I’m also submitting a session to give a talk on this same subject matter.

The Ask

A technical document of this type can take a lot of time to create and a lot of extra help to review it to ensure that all the technical information is sourced and as accurate as possible. Therefore you’ll see that I’m seeking volunteers (to help with the feedback/review process) and a modest level of sponsorship (to help move this project alone).

And as always, feel free to leave a (helpful) comment/suggestion below!

Let's Talk About PCI Compliance for Ubercart and Drupal Commerce.

2012-10-11T22:13:00+00:00

UPDATE: A white paper on Drupal PCI compliance is actively being worked on. Please visit the official website for more details.

Drupal makes it incredibly easy to turn even the simplest website into a full fledged commerce solution. All you have to do is download a few modules, check a few boxes, and you’re up and running in no time! Now you can sell your products around the clock to anyone in the world with a credit card. And because there is a strong focus on security within the Drupal community, it’s easy to convince ourselves that nothing can go wrong while we move onto building out the next feature or launching the next website.

When Things Go Wrong

The bank, the credit card company, the website owners, the customers: everyone’s happy as long as the transactions are running smoothly and securely. But what happens when a customer’s data is exposed and/or stolen? Who is responsible?

If I’m a brick and mortar store owner and I write down a full credit card number onto paper, then I’m liable if that card data is stolen and/or used in an unauthorized format. I’m also liable if I do something insecure electronically, such as email a full credit card number without encryption. Hopefully this is obvious, but I’ll underscore it anyway. If a customer’s credit card information can be exposed and/or stolen while it’s within our possession/jurisdiction or as a result of our actions, then we are (at least partially) responsible and liable.

Liability can be a hefty price to pay if a security breach occurs. Fines can go well into the 6-7 figure range and the ensuing PR nightmare can make it difficult to convince customers to trust you again. And if you want to accept credit cards at your store again, you’ll no longer be able to submit your own security assessment questionnaire. Instead, you’ll have to be audited by a 3rd party at a tremendous cost of time and resources.

The effects don’t stop at the individual company experiencing a breach. Drupal’s reputation for being a secure CMS/CMF can be severely undermined, even if it wasn’t the component that ultimately failed.

My Intention

Emailing credit cards should be an obvious no-no, and yet I still occasionally receive them in my inbox from web savvy individuals that I assume should know better. And I don’t believe that they were being careless or intentionally malicious. Sometimes they just didn’t know any better and believe things are far more secure and protected than they actually are.

I was in the very same boat with respect to PCI compliance when I began my Drupal career several years ago. “It just works” was good enough for me. And my colleagues, some of them with 5+ years of prior experience, didn’t seem to bat an eye when we fired up some commerce stores and began processing transactions. This was incredibly naive and stupid of me. But like an otherwise intelligent person emailing credit card numbers, I simply didn’t know any better at the time. And I didn’t get any major red flags when I performed several google searches and searched through the Ubercart threads. So I just assumed everything was ok…

Full disclosure: I have no certifications/credentials with respect to PCI compliance security. However, I probably have 200+ hours of self-study under my belt because there was no definitive guide for Drupal Ubercart and/or Drupal Commerce PCI compliance. Therefore I do feel qualified to have some opinions on the matter based on what I’ve learned, discovered, and implemented along the way.

The reason I’m writing this article is because it seems that everywhere I turn, Drupal developers and Drupal shops are still doing the equivalent of emailing credit card data with their PCI compliance requirements. This is dangerous and has got to change. And I believe the biggest reason this is occurring is due to lack of quality information (as well as the abundance of misinformation) within the community.

So it is time to have “the talk” with respect to PCI compliance and Drupal e-commerce. Let’s get a few major myths out of the way.

Myths About PCI Compliance within Drupal

Disclaimer: I’m not a lawyer and this is not legal advice. Everyone’s card data environment is specific to their configurations and business needs. The information below is my opinion and is accurate to the best of my knowledge. If anything is incorrect, I will do my best to fix it. Please do your own due diligence!

Myth 1: I’m not storing cards on my site, and therefore I’m PCI compliant.

FALSE. While not storing the card data does (significantly) reduce your PCI responsibilities considerably, it does not eliminate them completely. If the credit card data is still submitted to your site and passing through the Drupal form API, then your site + server is still processing and transmitting that data. If someone were to alter a line of code and/or intercept that data with a properly configured hookformalter, the card data could still be collected and distributed.

Myth 2: I’m using Authorize.net, and therefore I’m PCI compliant.

FALSE. Authorize.net (or whatever payment gateway you select) is one piece of the puzzle. And while Authorize.net can handle its portion of the process securely, your system is only as strong as its weakest link. Is your site running on a shared hosting environment? Are your Drupal security patches up to date? Do you have your SSL certificate properly installed? Did you turn on HTTPS?

If you’re accepting cards on your site, you’re probably PCI SAQ C. Reviewing all the requirements for this level (approximately 40) will give you a better understanding of your responsibilities.

Myth 3: I use Drupal Commerce, and therefore I’m PCI Compliant.

FALSE. Just because Drupal Commerce is newer than Ubercart does not mean that it’s compliant out of the box. A single configuration change can open up a security hole. Example: an admin logs in and disabled HTTPS browsing. Now a user’s session data and or form submission data can be sent in the clear and potentially stolen.

Myth 4: PCI Compliance is an extortion racket and I don’t have to comply.

TRUE and FALSE. There is also nothing compelling you to pay your taxes, until a government agent is knocking at your door. While I also think the process is more security theater than security, the fact of the matter is that you have to comply with their requirements for the privilege (not the right) to accept credit card payments on your site. And while this may seem difficult and annoying, there are other solutions available to you if if you or your client simply cannot put forth the time and energy to get your site fully compliant.

Myths 5, 6, 7, etc

I could go on, but I think you’re getting the point. PCI compliance is not so simple and blanket statements about Ubercart and/or Commerce being compliant out of the box are simply not true!

Solutions

It’s easy to be negative and point out what’s wrong, but what about solutions? If PCI compliance is so difficult and expensive, what can we do about it? I will do my best to give a concise overview and specific examples.

The PCI compliance standard targets 5 major security goals, which break down to 12 areas of focus (see here). In total, there are 288 possible items to be responsible for in order to prove your compliance. Thankfully, you can configure your system to offload or outsource a portion of those responsibilities to other people or services. The PCI compliance industry broadly groups 5 levels of responsibility: A, B, C, C-VT, and D. Typically, a website would fall into A, C, or D so I’ll ignore B and C-VT for now.

If you’re storing credit cards on servers that you personally manage or edit the code, then unfortunately you’re SAQ D and you have to comply with all 288 responsibilities. This can take most companies several months and hundreds of man hours to comply with and document. However, if you only process and transmit cards, you’re likely SAQ C. This sheds off almost 85% of the line items and now you’re down to 40 items to comply with. However it’s still a very difficult process. It also limits what types of services you can use. Example: don’t bother trying to use Rackspace cloud because you they don’t have a PCI Level 1 certification for their cloud server offering. You’re limited to managed only, and it still will require time and attention to get it up to spec.

The holy grail for Drupal eCommerce are PCI SAQ A solutions. At this level, you and your company are now responsible for only 12 out of the original 288 PCI responsibilities/requirements. And fortunately most of these items are easily achievable by just about anyone and within a few hours or days.

The easiest way to achieve PCI SAQ A is to configure an Ubercart or Drupal Commerce store to redirect to an external payment site (e.g. Authorize.net, Paypal, etc) so that they handle ALL the payment data before redirecting the user back to your site after a successful transaction. This type of redirection is called ‘outsourcing’ and is the only way (IMHO) to fully get to PCI SAQ A on Drupal.

The unfortunate reality is we all dislike this type of solution. Sending users to another site can be confusing and we lose control over what the payment site looks and feels like. It also limits our options of features and functionality. For example, using Authorize.net SIM doesn’t allow us to leverage their CIM services, such as card on file, which is usually needed for any site doing recurring billing.

This type of use case puts us into a bit of a dilemma. We either tell the client that we have to alter their business model OR we push forward with the feature set as requested and take on the PCI SAQ C responsibilities.

Tokenized Payment Gateways

To combat this, we’re seeing an emergence of a hybrid solution which can give us the best of both worlds: total feature flexibility with payments on site while still achieving PCI SAQ A. They are often described as “tokenized” payment gateway solutions. To understand why they are different, let’s first look at how a traditional payment gateway works.

In a traditional payment gateway with payment on site, the credit card first has to go through a series of validations within the CMS and then pass onto to the payment gateway servers from our website directly. While it’s doing this, shopping carts like Ubercart and Drupal Commerce do encrypt and protect this data as best as they can, but it’s still vulnerable to any deficiencies in our setup because it’s passing through our setup.

In tokenized solutions, the credit card data never touches our servers through the clever use of a javascript API. Now when the browser page is loaded on a clients computer, there is subtle but important difference. When the user clicks the submit button, the data is first sent directly to the payment gateway to validate the card first. If it validates, a one time token is returned to the user’s browser. Then and only then does the customers information and token get submitted to the Drupal site. Now the only thing passing through your Drupal site and servers is a token that represents the users card. When that token then arrives at the payment gateway again, the transactions is a success and the checkout process continues.

And if that explanation didn't fully make sense, check out this excellent step by step breakdown and infographic by Braintree Payments.

In short, the user never left the site and yet the payment never touches your servers. I can’t emphasize how awesome this is! Not only does this drastically reduce the amount of time and effort it takes to achieve PCI compliance, but it still allows you to leverage the full power and feature set of Drupal by keeping the customer on site.

What the Drupal e-commerce community needs is more of these PCI SAQ A solutions. Unfortunately, only a few exist for Ubercart and Commerce, which means we are still slogging through the SAQ C and D responsibilities… or ignoring them altogether. And with 45,000 active Ubercart installations and 17,000 active Drupal Commerce installations, we can not afford to keep ignoring these concerns forever.

Responsibility and Opportunities

Clients come to us because we are perceived as having expertise in an area of knowledge that they do not. And as consultants, I believe it is our job to not only help them achieve their vision but to alert them of decisions and directions that would be the equivalent of stepping on a landmine.

My hope is that we no longer find it acceptable, as a community, to create a hand over a commerce website without even mentioning the ramifications of PCI compliance. At the very minimum, we should at least point them in the right direction so they can ultimately navigate through this by themselves.

My hope is that when a potential client comes to us with a sub-$10,000 budget wanting a SAQ D commerce solution, we do one of 3 things: decline, educate, or upsell. We either walk away because it’s not right to hand over a ticking time bomb. Or we educate them into adopting a solution that fits their budget. Or we upsell them on additional contracts and services to perform a security audit and ongoing maintenance in order to achieve and maintain their compliance.

But in no way to do we simply walk them up to a minefield, wish them good luck, and run onto the next client. If we keep doing that, someone’s (eventually) going to get hurt.

A Proposal

Although this is a lot of material, we’ve really just scratched the surface. I typically like to be much more comprehensive with examples and citations, but we have to start the conversation somewhere. I hope that, at the very least, I’ve made my case that becoming PCI compliant is not as easy as turning on a switch or just making sure you’re modules are up to date. I also hope that this puts more pressure on the community to seek and develop PCI SAQ A payment gateways so that becoming compliant becomes affordable and achievable for every business wanting to have an eCommerce solution on their Drupal site.

But we’re not there yet…

In the meantime, I believe we need a more definitive PCI compliance resource tailored specifically to the needs of the Drupal community. Maybe this would simply be a series of articles (such as this) where we take on one aspect a time: starting with the needs and requirements and walking through a series of case studies and solutions.

Or perhaps the best approach would be a whitepaper like the one found at Drupal Security Report. In this scenario, we could have an all inclusive document that could be sent to prospective clients before a conversation about a commerce installation. Providing such material ahead of time could be extremely valuable, save a lot of time, and set proper expectations about what is possible given their vision and budget.

I’d be very excited to play a part in creating such a whitepaper and I also believe I would be a good candidate to take on such a task. During my PhD tenure at MIT, I successfully published 6 articles (yay for carbon nanotubes!) in peer-reviewed journals and in conference compilations as well as successfully defended my thesis. But I also know that I would not want to take this on alone, and would welcome additional authors, particularly those with extensive knowledge and experience in this field.

Continuing The Conversation

And if these articles and/or a whitepaper never comes to fruition, at the very least I want to spark this conversation…

Thoughts? Questions? Comments? Rebuttals? I’d love to hear from you!

Resources

Here are is a list of resources I’ve collected during my research and study. Some of them might be a little out of date or no longer relevant, but I did my best to update the labels so that someone other than myself would understand what they mean.

General Overview
User Experiences
- Adventures in PCI compliance
Ubercart Specific (Possibly Outdated)
Authorize.net Specific
- Understanding PCI Compliance
- How it Works
- Authorize.net SSL Certs for Sale
- Comparing Methods Within Authorize.net
- Method Tutorials
Drupal Security Resources
- Security Advisories
- Drupal Security Team
- Is Drupal Secure?
- Cracking Drupal: Book
- Drupal Secure Pages
- Writing Secure Code
- Simpletest
- Coding Standards
- Coder
- Drupal Security Report
- Drupal Security Report - PDF
- Scanning Solutions
  - Drupal Scout
  - Hacked
Amazon EC2 Hosting
Acquia Hosting
Rackspace Hosting
- Rackspace - PCI Overview
- What Does PCI Compliance in the Cloud Really Mean?
Detailed Standards and Documentation
Tokenized Solutions
- Stripe
- Braintree Payments
- Authorize.net HOSTED CIM. NOTE this is different from their standard CIM solution.
Drupal Modules That Can Achieve SAQ A (With Correct Configurations)

Drush Tip: Quickly Sync Files Between Your Environments With Rsync

2012-09-09T15:43:00+00:00

If you’re using Drupal best practices, you probably maintain different copies of your website (e.g. some combination of production, staging, development, and local development environments). But what happens when your local copy needs to be synchronized with the files you uploaded to your production server? If you need to do this a lot, automating the process can save you a lot of time and reduce the possibility of human error.

Here's a quick way to automate this file syncronization process using the rsync option within drush. Besides a basic drush installation/configuration, there are only two main items you'll need to place in a drush site alias file in order to set this up:

A path alias for each environment.
A shell alias for each combination of environments you wish to sync files (i.e. source1 to destination1, etc).

Adding a Path Alias for Each Environment

The path alias variable is a way to reference which folder you want to sync to and from on each environment. In this example, we are using the standard sites/default/files location and referencing it by %files variable.

// Site mysite.com, environment prod
$aliases['mysite.production'] = array(
  'parent'
  'root' => '/my/file/path/drupal',
  'uri' => 'mysite.com',
  'remote-host' => 'myhosting.com',
  'remote-user' => 'myusername',
  'path-aliases' => array(
    '%files' => 'sites/default/files',
  )
);

// Site mysite.com, environment local
$aliases['mysite.local'] = array(
  'root' => '/my/local/file/path/drupal',
  'uri' => 'mylocalsite',
  'path-aliases' => array(
    '%files' => 'sites/default/files',
  )
);

If you have any questions on what the over variables mean, simply checkout the examples/example.aliases.drushrc.php file contained in the drush module. Also be sure to add in entries for your additional environments if you want the option to sync to/from them.

Adding a Rsync Shell Alias

Once you have the path aliases set, the last part is simple one line addition at the end of the site alias file.

$options['shell-aliases']['pull-files']    = '!drush rsync @mysite.production:%files/ @mysite.local:%files';

Here I've created a simple drush shell alias called "pull-files." All I need to do is run drush @mysite pull-files and drush will pull down my files from production to my local environment using the settings in my site alias file. And if you'd prefer to sync from the development or staging environments, simply create seperate aliases for each possible combination you'd like (e.g. pull-files-staging, pull-files-dev, etc).

Additional Tips

Ideally you've properly configured/installed your ssh keys such that you don't have to authenticate with the external servers every time you run this command. And if you'd like to keep files in sync without having to think about it, you could also add this to your local crontab. Using this in combination with drush's sql-sync could be useful if you want to start each day or each new feature from a clean slate!

You Might be a Bad Drupal Developer If...

2012-07-22T09:12:00+00:00

You use Dropbox as your version control system.
You download and install 1000+ Drupal modules “just in case” you need them.
You give anonymous users permission to Views UI "so they can customize their experience."
You provide the PHP filter option for the comment field in order to find Drupal talent by seeing who can hack your site first.
You give anonymous users the “Administer permissions” privilege so they don't have to bug you in order to turn on a feature for themselves.
You claim "Ubercart is clearly PCI compliant” because of a forum thread starting and ending in 2008.
Your favorite IDE is MS word.
You place all of your site content into blocks instead of nodes (or other entities).
Your idea of upgrading a module from D6 to D7 is changing the version number in the .info file.
You routinely set the sites/default/files permissions to 777. After all, how else would you upload a file?
You pronounce “Dries” like you would the plural of the word dry.
You don’t realize @drupaltruth is being hilariously sarcastic.
You tried migrating from Wordpress to Drupal by replacing wp-config.php with settings.php.
You use snowpeoples as your favorite delimiter.
You went to JoomlaCamp Colorado and ended up here by mistake.
Your favorite way to ‘integrate’ 3rd party code is to use php includes from external urls.
You spend hours each week trying to get developers to ditch IRC and join your AIM channel.

Got more? I'd love to hear them. The funniest 20 will be used in a followup post!

Drush Tip: Use sql-sync to Quickly and Easily Move a Database

2012-06-02T18:37:00+00:00

If you’re using Drupal best practices, you probably maintain different copies of your website (e.g. some combination of production, staging, development, and local development environments). But what happens when your local copy needs to be synchronized with the latest content and configurations stored in the live production database?

If you’re not familiar with command line tools, the process can be super tedious. Typically it goes like:

Visit your production environment/website and login.
Navigate to the backup and migrate module page.
Export the database.
Visit your local development environment/website.
Navigate to the backup and migrate module page.
Import.

Not difficult, but if you have to do this even once a day, that time adds up. Before I knew this simple drush tip, I would spend as much as an hour doing a single sync because of the long waiting periods in between these steps for large databases.

It’s time to get that hour back!

Enter Drush’ sql-sync

Once you’ve created your drush aliases (this tip coming soon), you can run the following command:

drush sql-sync @server-alias.prod @server-alias.local --create-db

In a nutshell here’s what happens. 1. Drush tells the production server to dump a copy of the database in a temp folder on the production server. 2. That database is then secured copied to the local server. 3. Because we used the --create-db option, the current database is cleared out (by default, the import merges with the existing database, and that can be bad!). 4. The new, local copy of that database file is imported to the local environment.

That’s it! Sure, you can’t avoid the time it takes for the database dump, transfer, and import. However, that is all happening automatically from that one command, so you can go back to doing other things if the database is large and/or the connection speed is slow.

Additional Possibilities

This example was for just one direction and for one point to point transfer. You can also push in the other direction (NOT RECOMMENDED) as well as pull from a staging or dev environment to get specific changes. You could also chain them together at the same time to pull a copy of the production server to the staging, dev, and local dev environments all at once.

Now THAT is powerful stuff!

Additional Information

To effectively use this tip, you need to have some other configurations in your drush alias file located in ~/.drush. Here is an example excerpt from ~/drush/sitename.aliases.drushrc.php

$aliases['dev'] = array(
  'parent' => '@parent',
  'site' => 'sitename.com',
  'env' => 'dev',
  'root' => '/var/www/sitename.com/public_html',
  'remote-host' => 'remotehost.com',
  'remote-user' => 'username',
);

More on drush aliases and alias files will be included in a future tip!

Youtube Version

Comparing Drupal Ubercart and Commerce - Denver Meetup Presentation

2012-05-30T19:38:00+00:00

While smart money is betting on the Commerce module(s) as the goto e-commerce solution for Drupal 7 and beyond, the decision on which solution YOU should use today is not always easy. Because sometimes the answer is neither! To help cut through all the confusion and (hopefully) shed some light on the debate, I was invited to give a short presentation at the Denver Drupal meetup to compare and contrast the two. While the talk was by no means the definitive answer, it intent was merely to help people understand the key differences in and get started on their own evaluation.

The full video can be found here. A big big thanks to Denver Open Media for filming and archiving this video! We really appreciate it.

"If I Only Knew" - 7 Simple Tips to Improve Your Drupal Skills

2012-05-30T19:37:00+00:00

5 minutes—That’s all it took to find, enable, and configure a module that ultimately replaced the 40+ hours of custom work I just completed. And this was not an isolated incident within my 3 years of using Drupal. I still find myself reinventing the wheel versus using the ‘one thing’ (module/theme/patch/strategy) that’s already exists.

The art, of course, is knowing where that ‘one thing’ is amidst ALL the Drupal information out there. Even some of the top contributors bemoan how difficult to stay on top of it all.

My advice: Don’t give up! You don’t need to know everything to be effective. There are some very simple ways to grow bigger ears and stay generally informed without requiring a full time job’s worth of effort. Here are 7 simple tips to quickly improve your Drupal knowledge.

1. Follow Drupal Planet

Drupal Planet aggregates content from over 400 different Drupal related blogs and news outlets. Not only is this super convenient, but it gives you the ability to see a cross section of the entire community.

2. Get a Drupal Account

Do you know that less than 1% of all Drupal users actually have a drupal.org account? If you’re in this boat, you’re missing out on the ability to:

submit feature requests.
report bugs (and more likely see them fixed as a result).
join groups to follow conversations on a given topics of interest.
get job opportunity alerts.
user your user dashboard to quickly track all of the above.

I wish I had done this from day 1. I’ve gained a lot of wisdom as well as helped the community in lots of little ways.

3. Join a Drupal Group

If you are passionate about a given topic (SEO, geolocation, HTML5, etc.), join their groups! You’ll be in the loop and can even help direct the conversation by adding your input.

4. Go to a meetup

Meetups are a great way to interact with other Drupal enthusiasts in your area. You can make some friends, get tips, ask questions with more seasoned members of the community, etc. In my very first meeting, I learned about several modules and strategies that I used the very next day. It’s an amazingly useful resource.

5. Join IRC

Sometimes the fastest way to find an answer is to just ask a simple question. If you can’t find it on google, there are no less than 400 people in the #drupal channel of IRC who might know the answer. Many will actively answer questions and otherwise converse about any topic germane to Drupal.

6. Get their books

Online Drupal documentation is great, but I find it far too fragmented. Thankfully, their are entire collections of ebooks that cover just about every major Drupal topic available. I use them for both step-by-step examples, sample code, reference, and general knowledge of a given topic.

7. Listen to podcasts and screencasts

Companies like Lullabot produce a series of extremely useful podcasts, featuring interviews with top Drupal contributors. Companies like Commerce Guys produce screencasts to walk you through the beginning, intermediate, and advanced level details of setting up a store.

Your Advice?

Do you have a favorite tip? Leave a comment and I’ll add to the list.

The Basics of Content Type Design in Drupal

2012-05-30T19:36:00+00:00

Here is a simple video I put together to go over some high level tips and strategies for designing content types for a new Drupal site. Basically you want to remember 4 things:

Will I actually use this content type enough to warrant it's own designation?
Can I simplify the name to something generic versus overly specific?
Whare are the structure requirements for this type?
Can I simply use a tagging system to differentiate between similarly structured content?

The video includes the use of a mind map in creating a design.

11 Top Drupal Modules: In Layman's Terms

2012-05-30T19:34:00+00:00

For the impatient, click here to dive right into the list!

The joke goes: Drupal doesn't have a learning curve, it has a learning cliff. Funny, but only to those who have strapped on their boots and scaled this steep obstacle, falling numerous times in the process, but living to tell their war stories another day. The question is, is it worth the effort? Absolutely! Drupal is arguably one of the best (if not THE best) CMS's out there. It has amazing core functionality, a community filled with fanatical enthusiasts like myself, and a wide array of contributed modules to fill in all the gaps where you need things just right. And when that fails, you can customize it to your heart's content.

When you put it altogether, you can do just about anything with Drupal. That is, if you have the proper know-how...

Ready to scale the Drupal learning 'cliff'? Strap on your boots!
Image used under Creative Commons from Sirio.

For many, staring at the cliff in front of them can be paralyzing, but it doesn't have to be this way. If you just learn some of the basics about some key pieces and modules, you can at least know what is possible and explain your vision to someone who can fill in the details, and ultimately get the website you want.

The goal of this article is to give you the layman's lowdown on some of the top Drupal modules. Leave a comment if I could make the explanations even better!

1. Views

What it does: Views allows you to organize, arrange, and display your content based on a variety of criteria (date, time, tags, etc).

Simple example: You want to display a list of titles and dates (but not locations) of your next 12 events that are both tagged with NY and have a price of less than $100.

Unless you're a casual blogger, your website may have different types of content: events, articles, posts, videos, audios, etc. And just like it doesn't make sense to organize and display your photos in the same manner you would a collection of DVDs or magazines, you're probably going to want to display your website content differently depending on the content and the context.

Events: you may want sorted by date and only list the most pertinent information up front (date + location).
Articles: it may make more sense to display an image and perhaps a small amount of text.
Videos: showing in the sidebar doesn't make sense because they probably won't fit. So you'll at most want to show a thumbnail and title.

With views, you can set: your filters (which types of data), you sorting (alphabetical, by date, etc), your display (grid, list, full view), and a whole host of other options. It's so useful that I'd go as far to say it's a mandatory module to include and use on your site, even if you're 'just blogging.'

2. Fields

What it does: Fields allows you to specific types of information to content.

Simple example: An event may get the following fields: date, time, email address, phone number, location, contact person, etc.

When a lot of people think of websites, they think of simply copying and pasting text from a MS word document and (PRESTO!) the work is done. That's fine, but what if you later want to display only parts of that information? Use the event listing in the Views example above. If I just wanted to display a list of dates, I couldn't simply tell Drupal to psychically know which bits of information within the pasted text I wanted to pull out.

However, if I break things up into specific fields, then I have the option to display or not display them on a field by field basis. I can also rearrange their order. I can also validate and force people to enter a real email address versus adfasdf@afdfasdf.net (which garbage-like input that I typically use when I don't want to give a real address).

So fields provides a way to add a little more structure to an otherwise copy and paste blob of information. And if you ever find yourself asking: "Can I just make a list of phone numbers?" You probably should have used fields to divide up the pieces of your content and then used views to output it all.

3. Media

What it does: Provides a systemwide method to import, arrange, manage, and display your audio, video, images, and documents across the website.

Simple example: I want to upload a bunch of photos and then browse and paste them into specific article posts.

Most people who are not experienced with websites are surprised to find out that it's very difficult to simply 'paste' in their images directly into the site itself. So it can be a huge hassle to manage their media on their locale machine as well as navigate folders and such on the website as well.

The media module provides an elegant solution to this media management madness. It allows you to upload your media content once and essentially browse, access, and insert it everywhere else you want it. It does way more than this, but this feature alone will save you time and improve the quality of your experience managing your website.

4. Feeds

What it does: allows you to automate the importation of large quantities of data.

Simple example: a excel document containing product titles, descriptions, sizes, prices, and images is uploaded into feeds and then (POOF) 1000+ store items are now in your online catalog and ready to sell.

Moving from one CMS to another can be very difficult and time consuming. Plus, who has the time or money to do this all by hand? What feeds does is give you several options. You specify the format of your data (RSS, XML, CSV, or other tabulated formats). You specify where it's coming from (website URL or is this a file?). You specify where the data should go (events vs articles). Finally, you can specify how your data matches up to the fields you created ('product name' in your file excel file matches to 'title' in the Drupal content node).

So feeds is a wonderful way to save your sanity and get your content imported fast. Also be sure to check out the migrate module, which is similar in functionality.

5. Features

What it does: Allows you to save, revert, update, and move your custom configurations across multiple sites without having to manually re-enter them every time.

Simple example: I just created several content types (events, articles, case studies, people, etc) that I want to install on another clients website without spending several, tedious hours putting each configuration in one by one.

This module's name is a bit of a misnomer. When you hear 'features,' you're probably thinking of bells and whistles like what you'd find on a car: anti-lock breaks, power steering, etc. The features module would be more akin to copying these car features from one model (Ford Explorer) and automatically copying them into each other model (Ford Taurus, Escape) without having to start from scratch each time for features that are 95% the same in all cases.

So the features module is more of a container for things that you have created and want to save and port around with you. It's super useful. If someone changes your content structures, features will tell you your configuration was overridden. Want to revert it back? Just click a button. Want to install the same features for 5 different at the same time, the features module will save you hours of time and lots of tedious menu surfing.

6. Rules

What it does: When some event happens, do something if certain conditions are met.

Simple example: when someone logs in, send off an email to the website administrator if the user hasn't written an article in the last 2 weeks.

Rules are made up of 3 components: an event, conditions, and actions. Drupal core and certain 3rd party modules define a wide array of events that can be tracked, such as user events (logging in, logging out, posting comments), node events (content created, deleted, updated), etc. Conditions help filter out whether a response is necessary. We may not want to send an email off to every user in the system, but we might want to send a reminder along to a person who hasn't logged in for several months.

Rules are essentially a handy way of systematizing certain tasks in your website, which can improve the user experience and drastically reduce maintenance requirements. If you find yourself doing the same repetitive tasks over and over again, chances are you can setup a rule to handle it for you.

7. Panels

What it does: Allows you customize the spatial arrangement of how content lays across the page.

Simple example: I want my homepage to have a banner that spans full width, followed by 3 columns of text below that, and followed by 2 banners side by side on the bottom.

Clients love to imagine their webpages as a blank canvas where anything goes and every possible pixel is customizable. CMS's love to provide a more rigid structure by which similar content can pipe through and get a consistent look and feel across large sets of content.

One side wants fully custom, the other wants fully structured. This leads to a healthy tension to try and achieve the best of both worlds. Enter panels, an interface that gives site architects and designers enormous flexibility in how the content gets arranged on the page. And in addition to simple spatial positioning, one can even change what is displayed based a user's permissions and other contextual conditions.

So if you're unhappy with the rigidness of Drupal's block and region system, panels will be your best friend in giving you more flexibility in getting the layout and arrangement you want without sacrificing the power of and speed of using a CMS.

8. Drush

What it does: Allows you to completely manage multiple Drupal sites from a single command line interface.

Simple example: I have to update 30 modules. I could go to each module webpage, download, unzip, and move them all by hand over several hours. Or I could run "drush up" and have the entire process finish in less than 5 minutes.

This is mainly for command line geeks like myself, but don't let that scare you away from understanding the power and flexibility of this module/tool. Like every other major CMS, Drupal is constantly evolving both with bug fixes and feature enhancements. What this means is that there is always the need for continual, ongoing maintenance to make sure your website continues to operate smoothly. And even with a single, small website, thee sheer number of these updates can take up considerable time and mental effort to keep up with.

Drush is an amazing tool that is essentially an air traffic control for every Drupal website you operate. You can check the status, update, and manage multiple sites at the same time and without having to even load up a web browser. For those wanting to spend more time building sites instead of maintaining them, drush is an invaluable tool.

9. Skinr

What it does: Skinr provides a front-end way for site admins to change the look and feel of blocks of content without having to know the technical details in the back end.

Simple example: I want to change the color of my menu from blue to green, so I simply click the skinr button on the menu block and select the green style option.

Nobody likes a website that they can't control. Clients can be particularly upset when they realize they can't do minor tweaks (such as the change of a font color in the footer), without going through a long, convoluted process of editing CSS files, committing the changes, etc. They just want a different shade of red!

This is where skinr is extremely handy. Instead of just having a single design, a webmaster can create a series of styles and allow people on the front end to toggle between them. These style differences could be simple color changes, or night and day differences. Also, these skins can be exported and shared among many others as well, allowing designers to use their favorite styles over and over again across multiple websites.

Skinr is not quite ready for Drupal 7, but expect an update soon!

10. Overlay

What it does: Overlay allows you to access admin areas without leaving the page you were on in the public areas of the site.

Simple example: I'm viewing a iTunes-like catalog of my media and I'd like to turn on a module that adds a facebook like button. I can do this without having to navigate to the facebook settings page and then have to remember the exact URL I was at when viewing the catalog.

Many people don't really appreciate just how useful the overlay is. To me, it's the number 1 thing that sold me on Drupal 7. I was in the process of developing a catalog view for a piece of software I'm developing. When this started in Drupal 6, it was super frustrating to jump back and forth between pages all the time. I'd keep losing my place and I'd have to bookmark or create links for everything. I started to design my own overlay in jquery UI, but I really didn't have the time to create an entire interface from scratch.

But then I started playing with the Drupal overlay system and I was hooked immediately. I could now do all my back end changes and still not lose my spot. It sounds like a trivial, stupid thing. But try to go back to Drupal 6 after you get used the overlay, and you'll miss it dearly!

11. Administration Menu

What it does: provides you a simple, thin toolbar at the top of your browser where you can access virtually every possible administrative area on your website in a single click.

Simple example: Instead of clicking 4 times to get to the facebook like settings (/admin, then /admin/settings, the /admin/settings/fb_social, then /admin/settings/fb_social/like), I can now hover over each item and watch the sub menus appear, and get to exactly where I want in one click.

"Where the heck is everything?" I asked myself this question over and over the first time I started with Drupal 6. Yes, everything was neatly organized in a neatly defined hierarchy, but that meant you had to do a lot of poking around to see what exactly was 'behind door number 2.'

With the admin menu, you get one thin menu across the top that can get you virtually anywhere in the system within a single click. But beyond the mere speed and convenience, there is a more important benefit. You get the opportunity to explore the entire site structure from a single location. Once you understand the method to the organizational madness, you'll have a better idea of where to look for things when you need them next time. You'll also get better at predicting where new things should appear when you turn them on.

This is the FIRST module I turn on when I do a fresh Drupal installation. Without it, I easily double my time spent just getting around the site.

How can I improve this?

I make no claims that this is a definitive guide, nor do I claim I made this as clear as I could have. So I welcome any feedback, advice, or examples in how I could explain this even better. The better we are at communicating how to use Drupal for those facing the learning cliff, the more likely they will be in joining us on this journey and within our community.

Share the knowledge

And don't forget to send along to anyone else that would benefit from this simple set of overviews. If they get anything out of it, you'll be there Drupal hero!

Drupal word cloud image used under Creative Commons from Blamcast.net.

5 Reasons You'll Love Using Drush With Drupal

2012-03-30T19:29:00+00:00

The command line: most programmers love its power; most web users fear its (alleged) complexities. But for those willing to dive in, the reward is great. Using Drush on Drupal can save you several hours a week just on website maintenance tasks alone. Here is a short list to get you started:

1. Download and Install Multiple Modules Simultaneously

Installing modules on drupal is easy. You just have to

Go to Drupal.org
Search for the module's page
Download the module's zip file
Unzip
Move to sites/all/modules
Open up your web browser
Go to the modules page
Click off the checkbox for the module
Save your changes

That's 9 steps per module. And if you have 30+ modules to install, that can take up to several hours if you're not nimble with your keyboard and mouse. With drush, you can do it in 2 lines:

Download command:

drush dl addressfield admin_menu advanced_help amazon_s3 awssdk backup_migrate boxes calendar ckeditor ckeditor_swf coder commerce commerce_features commerce_feeds commerce_file commerce_product_key contemplate context ctools custom date devel devel_themer drupalforfirebug echo email emogrifier entity facebook_pull fb_social features feeds feeds_querypath_parser feeds_tamper feeds_xpathparser field_group filter_transliteration flowplayer getid3 globalredirect gmap google_analytics grammar_parser hacked html5_tools htmlmail i18n imce include job_scheduler jplayer jquery_update kfs libraries link location mailchimp mailmime mailsystem md5check media media_amazon media_browser_plus media_flickr media_youtube mediaelement menu_block migrate mimemail nice_menus omega_tools panels pathauto pathologic plupload quicktabs references relation rolereference rules search_api service_links services sexybookmarks skinr styles token transliteration viewfield views views_accordion views_bulk_operations views_pdf workbench workbench_access workbench_files workbench_media workbench_moderation wysiwyg xmlsitemap

Install command:

drush install addressfield admin_menu advanced_help amazon_s3 awssdk backup_migrate boxes calendar ckeditor ckeditor_swf coder commerce commerce_features commerce_feeds commerce_file commerce_product_key contemplate context ctools custom date devel devel_themer drupalforfirebug echo email emogrifier entity facebook_pull fb_social features feeds feeds_querypath_parser feeds_tamper feeds_xpathparser field_group filter_transliteration flowplayer getid3 globalredirect gmap google_analytics grammar_parser hacked html5_tools htmlmail i18n imce include job_scheduler jplayer jquery_update kfs libraries link location mailchimp mailmime mailsystem md5check media media_amazon media_browser_plus media_flickr media_youtube mediaelement menu_block migrate mimemail nice_menus omega_tools panels pathauto pathologic plupload quicktabs references relation rolereference rules search_api service_links services sexybookmarks skinr styles token transliteration viewfield views views_accordion views_bulk_operations views_pdf workbench workbench_access workbench_files workbench_media workbench_moderation wysiwyg xmlsitemap

The above commands may look ominous, but it's just drush 'command' and then a list of modules. Drush takes care of the rest.

2. Automatic Module Updates

Updating modules can be a pain. You have to check for avaialble updates, then repeat the process above in #1. Or, you can run: "drush up." This will tell drush to:

check which modules are installed on the current site
check to see if there are updates available
notify you what modules are out of date
ask you if you'd like to proceed
download all the modules and place them into the proper location
run update.php for you

This function alone saves me 2 hours a week.

3. Quickly Clear All Caching

You made a change to your site, but it's just not showing up! It might be a cache thing. Views, blocks, css, javascript: many components of Drupal are cached for performance. But this can make development difficult because you need to keep navigating to the admin areas to clear the system cache and flush the changes.

OR, you can run "drush cc all" to clear all the caching systems at the same time. This is super convenient.

4. Easy Backups

If you're developing on the bleeding edge (Drupal 7 with only dev versions of all of your modules, possibly with patches), you've probably experienced a corrupt database that simply could not be recovered. No fun. The easiest way to protect yourself is quick backups. But just like clearing your cache, you don't want to have to leave the page you're on and come back. Simply run "drush bam-backup" and a database copy will be generated and downloaded into the manual backups directory. For bleeding edge projects, I use this command compulsively because it's saved me so many times.

5. Control multiple sites

If you run more than one site (or a dozen sites), it can be tedious to manually update the modules at the same time. But drush allows you to create scripts and installation profiles, so you can quickly run the same commands on all of them. "drush @site1 up; drush @site2 up; drush @site3 up" would run the module update commands on 3 different sites, one right after another, without having to navigate your terminal to each site in between. This gives you a command center feel and allows you to connect to each site from one location, saving lots of time and focus for the bigger tasks at hand.

I hope you enjoyed this. If you have any questions or things to add, please leave a comment below. Are you using drush? If not, what's holding you back?

PS. If you're already a fan, you can buy the I heart drush here.