Breathing British Air

At long last I'm breathing British air and getting psyched for tomorrow's Drupal Commerce training. I lived in the UK for four years as a child but only have vague memories of a nanny and getting AG Bear and My Buddy for Christmas. I didn't come back with a nanny, but I did bring along my wife to help take care of me and my daughter to carry the dolls. We spent a few days in Paris recovering from jetlag, ringing in our fifth year of marriage, and finalizing training arrangements before riding the Eurostar to London with the rest of the team this afternoon.

We'll have a total of fourteen Commerce Guys at DrupalCon London, meaning we'll have plenty of people on hand to talk about Drupal Commerce. In addition to tomorrow's training, we'll be presenting / discussing the Commerce modules and contribs in BoF sessions throughout the week. To see the line-up, check the BoF schedule under Room 334. If we can record or screen capture anything from these, they'll end up on the Commerce Guys Vimeo channel.

I'm looking forward to the Developing with Drupal Commerce session on Thursday, because it will be me first go at leading a panel discussion instead of introducing all things Drupal Commerce in a solo, hand-waving, water-guzzling presentation.

I'll be joined by several other developers and business owners who have been bidding on and building Drupal Commerce sites since the alpha and beta releases. We're now gearing up for a 1.0 release thanks to the hard work and contributions of everyone on the panel. It should be valuable and entertaining to hear them talk about what it's like to develop with Drupal Commerce and how the core modules have evolved since they've been working with them.

Last but not least, for everyone who doesn't care a lick about e-commerce but likes Indian food, I have discovered the best Indian place in Croydon. Look no further than The Spicy Affair for a fair-priced, keenly seasoned meal (with a surprisingly kid friendly wait staff!). That's probably the most controversial statement I made in this blog post, and I can't defend it as though I'm some sort of connoisseur. If you know a better place, feel free to link it in. Otherwise I'll see you there.

Using containers as #states enabled markup form elements

As part of the sprint we're holding in Paris right now to introduce new Commerce Guys to Drupal Commerce development, we devised a situation where we wanted a conditionally available message on the checkout form. We decided for a shipping scenario that we wanted to present a message to the user regarding shipping costs inline with the address form if the customer selected a shipping address outside of the free shipping country of the store.

Adding a random text message to a form is trivial. You can just add a markup element to the form, using a div tag to make sure it ends up in a fieldset if necessary:

<?php
$form
['message'] = array(
 
'#markup' => t('What a wonderful message!'),
);
?>

Additionally, adding a #states array that includes the instruction to hide a form element on the basis of a select list's value is trivial:

<?php
$form
['message'] = array(
 
'#markup' => t('What a wonderful message!'),
 
'#states' => array(
   
'invisible' => array(
     
':input[name="select_list_name"]' => array('value' => 'US'),
    ),
  ),
);
?>

Unless I botched my pseudo code, that #states array should instruct the Form API to include JavaScript to hide the element when the select list I specified has a value of US. Unfortunately, that code won't work. Shocked

The problem is that the JavaScript that hides the element depends on the element's ID to target the behavior, and a markup element by default gets no wrapping. This means you can't directly put a #states array on a markup element in general. You do have a few options to work around this, and I'll end with what we went with in our case... you can tell me if we're crazy. Sticking out tongue

  1. You could just hardcode a div wrapper that includes the ID and the form-wrapper class Drupal expects, but I can't say that I'd recommend it. Names change quite frequently during development and can easily be altered.
  2. You can also just put the markup element inside a container element and attach the #states array to the container. Containers are rendered as divs with proper IDs for targeting, so this works just fine.
  3. However, we wanted a compact solution, so what we did is turn the markup element into a container element and set its #children property to the message. This effectively makes the container element function as a markup element, but it actually wraps the markup in the appropriate div on output. Since #children is already set, this does mean that the container element cannot actually contain other elements, so there may be good reasons for you not to try this at home.

The gist of our solution was:

<?php
$form
['message'] = array(
 
'#type' => 'container',
 
'#children' => t('What a wonderful message!'),
 
'#states' => array(
   
'invisible' => array(
     
':input[name="select_list_name"]' => array('value' => 'US'),
    ),
  ),
);
?>

I suppose it would be nice if we didn't have to abuse the #children property name, but this seems like fair game to me unless it's a possibility to change the markup element to include the div and expected ID.

Drupal Commerce in a git.d.o world

Because we were doing our Commerce module development on GitHub and exporting to CVS, we need to make some changes now that the Git migration on d.o is complete. Obviously the main Git repository for the project is now on d.o instead of GitHub. To clone the latest code, you can follow the helpful Git instructions included on Drupal project pages.

All of my D7 projects now include a 7.x-1.x branch that you should track to get the latest commits. I also updated the various dev releases of Commerce, Address Field, and my Commerce contribs to be snapshots of this branch, essentially deprecating master. I'm trying to decide the best thing to do about those pesky master branches and will likely just git rm everything in them and leave behind a README indexing the various HEADs in the repository.

Many people had forks of both the old Commerce repository and my development repository on GitHub. Additionally, some of you may have pending commits that haven't been pulled yet. If this is the case for you, please generate a patch instead of a new pull request and post it to the issue queue. As of this point I have no plans to rewrite the commit history of the new official repository to match the existing history on GitHub, meaning I cannot cleanly pull from your repositories.

(I have read Ben's blog post, and I'm sure there are some other finer aspects of Git that I'm just ignorant of to accommodate this... but I'm not sure it's worth the hassle when forks will need to be updated across the board anyways.)

This seems a little brute force, but I think it's for the best. The commit graph on d.o is now a nice tidy straight line, whereas the old graph on GitHub was a fractured mess that included several instances of duplicated commits thanks to botched merges and branching. We were still learning an appropriate Git workflow at the time and made several mistakes that not only dirtied up the history but also made it hard to sort out how to pull from various forks. (Accordingly, current contributor statistics on Ohloh are inaccurate anyways.)

This does mean some contributor credit in the commits will be lost, but I'll be updating various project pages to credit beta contributors for their commits. Regardless, I've been crediting contributors in commit messages all along, and merge commits show whose repository the merged commits came from. As of this point, I think the loss of a little meta information is worth the clean slate with the new repositories. Flame away in the comments if this is the stupidest idea you've ever heard... just want to make sure my plans are clear.

While we figure out how to handle pull requests in an environment that doesn't natively support them, in your issue please indicate your repository URL (whether it's a d.o sandbox of GitHub fork) and branch that I should pull from to compare. Bonus points for attaching a patch for quick review on site (or linking to the diff on the appropriate web interface). I'll add your repository as a remote so you don't have to post it every time. Additionally, I'd prefer it if you used a single branch per issue you're addressing with the branch name simply being the nid of the issue - makes it quite easy for me to branch and pull locally.

(I should mention that the good ol' patch process is perfectly fine if you don't want to maintain a public repository for me to pull from. You can just make your commits locally and diff 'em all in one fell swoop to create a patch for review.)

This is essentially what we've been doing on GitHub, so no surprises here for existing contributors. I'll leave the GitHub repos up for a while, but I'm updating their READMEs to point to the new repository on d.o. Once tested and approved, these guidelines will find their way into a handbook page for posterity's sake.

Calling all pre-beta testers

This is a quick call for help before I package up a beta release of Drupal Commerce. The last few weeks I've been working around the clock on blocking issues, dependency issues, Rules based pricing and tax (incl. VAT) support, and last minute database tweaks. My wife has been incredibly supportive of me thus far, but now I need help from my friends with a bit more technical acumen.

Here's the deal: for all intents and purposes, this code is beta ready. Database schema changes have mellowed out. The modules have solidified. The core feature set lets you start selling quickly. The Views and Rules integration provides for some fine standard interfaces and workflows. The last few weeks, pcambra has been our SimpleTest hero, and now he's working with recidive to flesh out the functional tests even further.

What it really needs is eyes. Your eyes. If you have a few spare moments, you could greatly help by testing an installation and ensuring there aren't any crazy bugs that I just don't see because of my development environment or selective blindness. These could take the form of installation bugs, odd default configurations in Views / Rules, typos, broken access control, and more. There are bound to be things I'm missing, and I really need your help to know what they are.

Here's how to get started very quickly:

  1. Download Drupal 7.
  2. Download into your sites/all/modules directory the latest dev versions of the following dependencies:
    1. Address Field
    2. Ctools
    3. Views 3
    4. Entity API
    5. Rules 2
  3. (Note: Getting these from CVS would be better to get their latest commits.)

  4. Download into your sites/all/modules directory my Git dev version of Drupal Commerce (or just git clone git://github.com/rszrama/drupalcommerce.git).
  5. Download into your profiles directory my Commerce Dev installation profile and download into your sites/all/modules directory Admin Menu (a dependency of the installation profile).
  6. Now install Drupal 7 using the Commerce Dev installation profile and see what happens!
  7. If you're feeling adventurous, use the Standard installation profile and then try to enable the Commerce modules manually to make sure the standard install process works. (You'll have to adjust some permissions, enable the cart block, and build a product display node type from scratch - read more about that in the first issue of Drupal Watchdog. )

Once it's all installed, cruise through the various admin interfaces, settings forms, and front end features and let me know what breaks. Note, I'm not looking for support requests, "How do I...?", or feature requests, "Needs flat rate shipping support." Rather, I want to know what, if anything, of the core feature set just doesn't work.™

One of the latest features to test will be to configure a tax rate for your country / state. Simply browse to admin/commerce/config/taxes and add the tax rate. If you made it a sales tax, it'll show up once you get to checkout. If you made it a VAT, it'll show up inclusive in product prices. Additionally, if you made it a VAT, you can edit products and enter their prices including VAT. Taxes work through the same Rules event as other product pricing rules, so you can try adding a discount rule and fiddle with its weight to see how it interplays with your tax rules.

Drupal Commerce comes with an example payment method module that lets you just put a name in on the checkout form to test payment. You can test additional payment methods if you have developer accounts for Authorize.Net, CyberSource, or PayPal.

Please report any bugs you can turn up (or +1 existing bugs) in our issue tracker. I'll also be hanging out in #drupalcommerce on irc.freenode.net if you're into IRC.

While you do this, I'll be running tests of my own, reviewing the names and descriptions of all our permissions, and ensuring the customer profile integration with Checkout and Order administration is up to snuff.

With any luck, we'll all be beta testers tomorrow.

Pages