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?").
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.”
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.
- 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.
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:
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 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.
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.