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.

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.

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.

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.

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.

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.

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?

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.

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 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?

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.