Drupal 8 is now ready for production use, with RC1 released just recently. This also means that work on D8 contrib is accelerating, and everyone is curious about when they can start their first eCommerce sites.
A production ready Commerce 2.x beta won’t happen for another two months. However, we’re ready to start releasing related modules, tag Commerce alphas, write documentation, and track our progress more publicly. Starting from today we’ll do weekly blog posts showing the current state of Commerce 2.x. And for the people who want to build the future instead of just anticipating it, we’re holding IRC meetings every wednesday at 3PM GMT+2 on #drupal-commerce.
Lars Oleson is a native of Denmark and a school teacher by trade. He's also the co-maintainer of Commerce Kickstart v2 and a community member who has brought a lot of positive changes to the project.
Say hi. (who are you and what do you do in the Commerce ecosystem)
I am just a random guy who contributed a little time, effort and work in the issue queue.
How did you get involved with contributing to Drupal Commerce?
I got interested in Drupal some years ago when I grew tired of maintaining my own little systems for different websites. I created a site both for my workplace (vih.dk) and for my little frisbee shop (discimport.dk). I thought Commerce Kickstart was a very cool starting place for creating a shop. The 2.x branch just started to take place, so it had a couple of hiccups at the alpha and beta-stage. I started reporting issues in the issue queue - and had a very good response for especially bojanz every time.
I'm excited to announce the arrival of a new phase of contribution for Drupal Commerce for Drupal 7. While there is a large group of developers focused on updating and readying Drupal Commerce for Drupal 8, there is still a need for many of us (me included!) to enhance and improve the current, stable version of Commerce. To that end, I'm helping to establish a regular update and refresh that is sponsored through my work at Commerce Guys.
The goal of the Commerce 7.x Sprint is to provide a common community push to sprint on the Drupal Commerce ecosystem at large. This will be handled using coordinated office hours in the Drupal-Commerce IRC channel and a new issue tag, commerce-sprint.
Commerce Kickstart 2.27 was released today, and includes quite a few bugfixes and features. Recently Commerce Kickstart 2 upgraded from Features 1.x to the Features 2.x API, and we've added some measures to help with the upgrade process! If you're not using Features Override yet, go on get it! Use this to save your customizations to the distribution and have a smoother upgrade. For more information, see the Installing & Upgrading guide.
Our users may need to log in to any of these services, and sometimes several at the same time. So we needed to have a shared authentication system, a way of synchronizing user accounts, and single sign-on (SSO) functionality.
After a lot of research on the existing methods, such as CAS, we found that there was no generic open-source solution which would cover all of our current needs and would also allow us to grow and scale in the future when adding new features or applications.
We decided to implement the OAuth 2.0 and OpenID Connect protocols, which were designed to be flexible, yet simple and standardized - exactly what we wanted.
Heretofore, shipping has focused on exposing a simple yet effective API for connecting rating and shipping companies to the checkout process. Many stores eschew real-time rating and instead opt to offer flat-rate shipping or free shipping on orders. This entirely removes the need for rating. For those who do use real-time rating, the existing process offers a simple set of tools that are only adequate for simple shipping needs.
It's not uncommon for a Drupal module to need an external library in order to function. Historically, modules such as oauth2_server have done this by asking the end-user to download the library manually and extract it into sites/all/libraries. A hook_requirements() implementation would nag the end-user until the library is found.
Nowadays, all libraries are registered on Packagist and expect to be installed via Composer, which also resolves and downloads their dependencies. Thanks to Composer and modern PHP, the number and usage of libraries has skyrocketed, with Packagist recently counting its 500 millionth package install. Because of this thriving ecosystem, it is now more desirable than ever for modules to depend on libraries instead of reinventing the wheel. Furthermore, it is desirable for modules to release their core logic as libraries, bringing in additional users and contributors from the wider ecosystem.
Many people know that addressfield hasn’t been the easiest module to maintain. There are over 200 countries in the world, each with its own addressing requirements. Addressfield attempted to provide a sane default for all of them, along with a plugin architecture for handling per-country customizations. But with so many countries, the list of needed improvements became never-ending, and the customizations themselves started gathering in only one plugin (address.inc), which quickly became impossible to maintain.
A radical change was needed, so after a lot of research we introduced a new plan for Drupal 8, along with a brand new PHP library we can depend on from addressfield 8.x-2.x. The new plan resolves around two powerful ideas:
The introduction of address formats, which hold information on how a country’s address and its form need to be rendered and validated.
The use of Google’s addressing dataset, freely available and built for Chrome and Android, with address formats for 200 countries.
The introduced solutions were obviously superior to anything we had before that, but Drupal 8 is still far from production, and we needed improvements on our Drupal 7 sites today, so we decided to try and backport as many concepts as we could into the 7.x-1.x codebase. The result of that is addressfield 7.x-1.0-rc1:
When working on a Commerce project which uses a payment gateway, you need to always make sure that your Staging and Development environments are properly targeting the sandbox or test mode of your payment gateway, and that your Production site is targeting the live account.
This is actually true for any third-party service integration which provides a sandbox where you can test. The objective is to make sure you never send test data on a live account, no matter the service you're testing on.
For this tutorial, I will focus on payment method settings, but the principle remains the same for any other third-party integration.
I will start from an empty Drupal site hosted on Platform.sh and go through the following steps:
Well, there's lots to talk about for Commerce 1.x as well. Over the last few months, we've released a number of features that are definitely useful for over 50,000!! existing Drupal Commerce stores and good to know about for future shop implementations: