Work

Well, Christmas is already over for a lot of you, but there's still an hour left here in the States for me to wish everyone a Merry Christmas with a Drupal Commerce Alpha 4 release. I drove down to Louisiana to celebrate with my wife's family, and for once I took the passenger seat and got a good bit of work in to tighten up our Entity / Rules integration. Éowyn had a meltdown after 8 hours, too, so thanks to the Super 8 Motel in Wheatley, AR, I made even more headway on the dynamic Add to Cart form and its dependent attribute display.

However, integration and maintenance issues aren't the most exciting things in this release. I'm much more excited to announce the extensive work done on Drupal Commerce's Rules powered dynamic pricing system. We now have a centralized system empowering site builders and store administrators to implement pricing rules for discounts, tax calculation and display, and currency conversion through the user interface. While some of the subsystems still need attention, the Rules are in and working on the Calculating the sell price of a product event. You can see the results immediately on product field displays and in the shopping cart.

For example, I might want to give members to my Wombat Dating site a 10% discount. Never mind the absurdity of the scenario (if that's even possible) and see the basic product display node showing the product image and price fields:

The price field is displayed with the Formatted amount display formatter, which knows that modules are enabled that allow for dynamic price calculation:

This particular calculation option allows product sell prices to be calculated through Rules, so I've setup a 10% Members Discount using this simple rule configuration:

The end result, as you would expect, is a much cheaper night out on the town with our lovely wombat:

This system is a huge step forward from what we attempted in Ubercart, which lacked a baked in UI, touched every price on the site, and involved a pretty heavy caching system that couldn't address the problem of executing queries based on calculated prices. The system eventually got the boot, but we got a chance to tackle the challenges afresh with Drupal Commerce. Through some good discussion at DrupalCon Copenhagen with Damien, Miro Dietiker, and others, we realized the problem was actually in how we understood our dynamic pricing needs.

The first thing we did was restrict our initial scope to calculating product sell prices. That solved a lot of performance problems and API confusion on its own. However, we still had to solve the querying problem since we're depending on Rules to perform the calculations. This means we require PHP to execute to find the actual sell price of a product for any given customer. Simple queries that order and filter lists of products based on the sell price would be inaccurate once the price was altered for display, so a customer with a special discount on a product won't see it at the top of a catalog View when he orders by price. We've run into this problem several times at Commerce Guys, especially when displaying prices with tax included.

What we determined was that we needed to pre-calculate dynamic prices so the data would exist in the database before a customer ever needed it. Since we know the Rules attached to the price calculation event, we can pre-calculate prices for every combination of applicable Rules. The pre-calculated price data can then be joined into queries for any given set of Rules, enabling ordering, filtering, and faceting to work with actual sell prices instead of just the base price stored on the field. There are some guidelines to follow when constructing Rules for pre-calculation, and we've also devised a few simple ways for larger sites to keep the calculated price table from breaching epic row counts.

If I lost you, my apologies. It's very exciting stuff for the project, and I tend to talk too much about it. I've already explained it to all of my in-laws, including my 75 year-old grandfather-in-law whom I'll be teaching Drupal while I'm down here for his personal website.

I'll be blogging more about the dynamic price pre-calculation system, especially once it gets an actual user interface. For now it's a small API and a database table, but it's itching to be put through its paces. I'll be testing it first with Views and welcome additional eyes on the code. For more information on how it functions, refer to the development specification and the copious amount of comments on the pertinent functions in the Product Reference module.

Anyways, I've been closeted up with the laptop enough for one Christmas, so I'm going to join the rest of the family with some doctored eggnog and a seat in front of the fire. I hope you all had a Merry Christmas, and I look forward to feedback on the new hotness in Alpha 4.

Check out the release notes for the full changelog since Alpha 3, If you're thinking of resolving to visit Paris for the New Year, check out the details on our Paris Commerce Sprint, January 17-21, 2011 and consider joining us in Paris to push this code from a planned beta to 1.0 in time for DrupalCon Chicago. We'd love to have you.

This last week's development on Drupal Commerce has been a flurry of exciting commits for me. Ever since the first demos I've been talking about how the Add to Cart form will be able to use field data to let customers choose products by their field values instead of their titles. Similarly, I've talked about dynamically updating field data on the page so images, prices, and other fields are re-rendered to reflect the currently selected product.

Until now these features have been relatively low priority, as we focused on the other major core systems. However, with the release of 7.x-1.0-alpha3, they have finally moved from the hypothetical realm into code awaiting your testing.

The screenshot shows three features of Drupal Commerce product displays:

1. Product fields from the default product are pulled into the node display via the Product Reference field. The pictured display actually references 12 separate products representing different color / size combinations.
2. The Add to Cart form display formatter turns product reference fields into forms. It creates attribute select lists using field data from the referenced products, only including options that actually exist on products referenced by the field.
3. As options are selected on the form, the product fields displayed on the page are updated to reflect the currently selected product. The options on the form also update to show newly available options, allowing for attribute dependencies to any depth in their order of appearance on the form.

In other words, as I choose a color option, the size select list updates to only list sizes of the shirt available in that color and the image can change to show me wearing a different shirt. If the size is changed to a more expensive option, the price on the page updates accordingly. I'm sure this description hardly does the features justice, so I'll get a screencast and live demo up next week for you to play with.

This behavior is all thanks to the new #ajax property in Drupal 7 and required no custom JavaScript to work. When a select list's value changes, the form is submitted and rebuilt server side giving me a chance to change the available options. My #ajax callback uses a set of AJAX commands to direct the replacement of the existing form with the newly rebuilt form and works alongside the product reference field to re-render and replace any product fields on the page as necessary.

(On a side note, if you need to do full form replacement yourself, be sure not to target the form using its id. Each time it is rebuilt, the HTML id is incremented by drupal_html_id(), so the replacement will only work the first time. Instead, either target a container within the form or some other selector that won't change each refresh. This cost me a few hours. )

Other features of note in this release include:

• The order edit form has taken shape with vertical tabs, revision logging, and working customer profile reference fields.
• All currencies have been defined with updates to the Price field accommodating multi-currency stores. Currency rounding now accommodates currencies like Swiss Francs, which rounds to the nearest twentieth (thanks to das-peter). Only known currency formats are implemented, so you may need to open an issue for yours to have proper formatting (i.e. $100.00 vs. 100.00 USD).
• The Payment module received more work since the last release to support credit card payment methods. I've created Commerce Authorize.Net as a proof-of-concept and example implementation for other developers to follow. (Some code specific to that module right now will be abstracted to Payment, like a general handler for prior authorization captures.)

More information and a full commit log are available in the release notes. I'm very grateful for the efforts of community contributors, especially das-peter for his help on the currency issues and our Entity API and Rules integration.

There's still plenty of work to be done, so feel free to join is in the issue queue.

Blog's been a bit sleepy as of late... so sleepy it managed to miss out on two trips to Europe for DrupalCon Copenhagen and E-commerce Paris 2010, the first Drupal Commerce alpha release, and my daughter's first steps and first birthday.

Does it work to just say they were all awesome and move on? My wife can testify that many things in my life back up to a point where a dearth of activity stymies said activity's resumption... or simply put, when I stop doing something I want to do for an extended period of time, I find it hard to start again.

Ok, </introspection>. I'm breaking the ice with a happy announcement - I managed to package up Drupal Commerce 1.0-alpha2 in the wee hours of the night.

The release notes provide an overview of changes with a full commit log since the alpha 1 at DrupalCon CPH. The new alpha and my development installation profile have been updated for Drupal 7.0-beta1, though I still need to update our Fields to take advantage of display formatter settings.

The highlights of the release are:

• Functioning Payment module with integration points for on-site methods (demonstrated by the core Null payment module) and redirected payment services (demonstrated by PayPal WPS integration in Commerce PayPal). Payment service integrators would do well to jump on board so we can take care of any workflow issues, especially for redirected payment services.
• SimpleTest base class for Commerce testing provided by Jeremy Blanchard, complete with documentation and related issues. It's just begging for you to start using it...
• Updates to the price object to allow Rules based transformation of prices prior to purchase and/or display; still requires some implementation as outlined in a rambling Google Doc.
• The Specification handbook at DrupalCommerce.org has received some love to get it up to speed. A major goal for the project was to not have undocumented major releases, so I've begun documenting the various system components and will then move onto the system overviews. For now only the sections on our info hooks and core API utilization have meaningful content. Feedback on the structure is most welcome.
• A host of bugfixes and API / variable naming standardization. The documentation effort really helped here, so I expect similar results as I catalog the Commerce Entities and Fields.

The release is also accompanied by an alpha release of Address Field, a dependency the Customer module uses to collect name and address information during checkout according to the xNAL standard. This module took some massaging to get working, because it defines a Field that uses #ajax to update address form elements based on the country chosen. It now works no matter where I embed the widget, even if I'm doing something crazy like embedding the customer profile entity's field widgets in the checkout form... but that's a topic for a follow-up blog post.

That's all to report for now. There's plenty more activity and good contributions coming through the issue tracker. As this alpha's release was dependent on a fully functioning Payment module, the next alpha release will be dependent on the full implementation of dynamic pricing as outlined in the doc above. We'll also push to get as far as we can on the order administration UI and show some love to product and line item display in the meantime. We'll stay busy!

January seemed to breeze along without really stopping to say hello, and February doesn't look to be slowing down either. af83 will be hosting a Drupal Commerce Sprint in Paris from February 22 - 26, and we'll be doing as much as we can to make sure it's a productive time. I'll be flying over with mikejoconnor to join DamZ, Bojhan, fago, and whoever else shows up to work on the core Commerce modules and Rules 2 for Drupal 7. We're very excited about the week and doubly excited about the chance to work with Bojhan and fago early in DC's development.

If you're interested in joining us for a week of hard core Drupal in Paris, sound off in the forum thread for the sprint. We'll keep potential attendees notified of plans / IRC meetings through that thread. We're looking to finalize attendees by the 15th and draw up our battle plans to maximize our time together. I can't wait!

Costs will mostly be covered by Commerce Guys and af83. However, if you can't make it but would happily send someone in your stead, stay tuned and we'll post up links to the appropriate chip-ins.

I had a great time last weekend taking part in DrupalCamp Austin as a learner, a helper, and a presenter. I also enjoyed sharing an apartment and eating meat (and/or ice cream ) with my fellow Commerce Guys, Mike and Tim, and it was doubly fun to get reacquainted with folks I hadn't seen since last year's Drupalcon Szeged or Do It With Drupal.

As a learner at Drupal events, I tend to benefit most from sessions that discuss meta issues in Drupal development... how to grow your community or business, interact with clients, deploy and manage sites in the wild, etc. Ben Finklea of Volacci didn't disappoint with the weekend's opening keynote session, Building a Successful Drupal Business. He focused a lot on building good business processes for tasks ranging from managing sales leads to hiring. I missed out on Ben's SEO chat later but actually had the pleasure of joining him for church on Sunday morning, a rare opportunity on a Drupal weekend!

As a helper, I had fun doing a little bit of Drupal / Ubercart triage in the Commerce Guys room. Myself and a few other experienced Drupallers fielded questions and offered site building advice to various folks looking to iron out issues with their latest sites and prepare for upcoming projects. Aside from the communal eating of meat and ice cream (see above... and below), this is probably my favorite part of Drupal events.

Last, as a presenter I walked through the installation and configuration of Ubercart starting with the UberDrupal installation profile. It's not perfect, but it gets the job done and helped folks in the audience visualize how to use the sweet Acquia Prosper theme and leverage Ubercart's core systems. I was scheduled to discuss the ongoing Ubercore Initiative the next day, but most in the crowd were there because they had chosen Panels over Ubercart the day before. So, with a slight adjustment, I presented another Ubercart overview with glimpses of the plans for future development (like those in my last post on products). Those interested in learning more than that session afforded should hop in the #d7uc IRC meeting scheduled for Nov. 20 at 1 PM EST and keep an eye on http://d7uc.org.

On the recommendation of Todd Nienkerk of Four Kitchens, I drove the rental with Mike and Tim down to Driftwood, TX (nowhere near a beach) for some Salt Lick BBQ. They brought us plates piled with meat fresh from the open fire pit, treating our taste buds through our yummiest business planning meeting ever. Here's hoping there's a trip to Austin (for Drupal and/or BBQ) in my future!

This next week I'll be taking my show on the road. After a high school friend's wedding this evening, I'm driving with Christina to Abingdon, VA where we'll stay with my grandparents for the weekend. We'll be meeting my older brother and sister-in-law there for some hangin' out and some play action - The Fantasticks at the local Barter Theatre. It should be a fun weekend!

On Sunday evening or Monday morning we'll drive down to Greenville, SC where I'll set up shop in their "bonus room". It'll become my new home office for a few days while we spend the evenings visiting with family and loading up on baby shower loot. I love spending time with my in-laws, so the week should be a real treat.

Even better... we won't have to leave our house unattended that whole time! Some friends are in between leases at two apartments and have agreed to come babysit Top Porch and our awesome veggie garden while we're away. Sheets changed, clean towels out, floor vacuumed, and chocolates hidden. Hah!

For some time now, my standard operating procedure for writing new modules to client specifications has included a tedious conversion of database tables into schema arrays for use in each module's install file. Usually, I'd begin with copying and pasting into the install file a schema array I'd used elsewhere, and I would modify that array to match up to the table I had thrown together to store the module's data while testing. I would then have to go through the process of uninstalling and re-installing my module to make sure I didn't mess up the schema somewhere. Lo and behold, at the end of May I learned about the Schema module at an event where I was supposed to be the instructor. I must have missed this somewhere along the way when converting all my code to Drupal 6, but it sure does make new module development a lot easier! The Schema module offers several features for examining the tables in your site's database and comparing them with the schema data defined in your site's module install files. If you use it for a full inspection of your site's database, any table it finds that does not have a matching schema array will be listed on the page with a schema array already built for you. It even includes little placeholders where you should insert table and field descriptions. So, now with the Schema module, I can copy and paste the auto generated schema array into my install files, making module development that much faster. I'm really digging it. One pitfall that you should be aware of: if you're using drupal_write_record() to insert and update rows in these new database tables, you must copy the schema arrays into your module's hook_schema() before it will work. If drupal_write_record() can't find the schema array for the table to which you want to write the record, it will not be able to construct the insert or update query properly. Remember to clear your cache (by visiting the modules page, for example) before testing it so Drupal can rebuild the cached schema data. I hope it makes your life easier, too! Many thanks to Barry and the other Schema maintainer(s).