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:
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.
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:
The video includes the use of a mind map in creating a design.
