Allow rules to control which panes are visible during checkout

Looking at the code, it appears that even though you can alter out panes from the form w/ hook_form_alter(), there's no way to change the submit handlers invoked upon form submission. That's a shame... the only thing you'd be able to do is use hook_commerce_checkout_pane_alter() and disable a pane based on the cart order... if you're doing this, make sure your implementation of the hook restricts itself to checkout URLs so it doesn't interfere with administration.

I'm not sure we need to make pane visibility Rules powered, but at the very least it should function as advertised when altered. To whit, we should probably be keeping in the form array a list of checkout pane submit callbacks to call (so they can be altered as necessary) instead of just getting them directly from the pane objects themselves like we are now:

foreach (commerce_checkout_panes(array('enabled' => TRUE, 'page' => $checkout_page['page_id'])) as $pane_id => $checkout_pane) {
  // ...
}

Did you mean hook_commerce_checkout_pane_info_alter instead of hook_commerce_checkout_pane_alter() ?

See sample code http://drupal.org/node/1228342

@rszrama

I'm assuming that you meant hook_commerce_checkout_pane_info_alter() as I canoot find a hook_commerce_checkout_pane_alter().

Does anyone know if it is possible to get the cart / order contents )$commerce_line_items) from within hook_commerce_checkout_pane_info_alter()? The information doesn't seem to be available in the object passed into the function.

Figured it out, from anywhere you can get the current user's $order with:

global $user;
$order = commerce_cart_order_load($user->uid);

Thanks to #drupal-commerce :)

hehe Awesome. And yeah, my bad - it's hook_commerce_checkout_pane_info_alter(). : O

Does this work to control checkout pane workflow from code on a per user basis, as per #5 using the cart loader function?

For example, I want to disable panes that don't need to exist for certain product types. Currently, I have two a generic Product (physical items) and a Registration (Commerce Registration + Registration). For physical items, we'd like to collect Billing Info, Shipping Info, and Payment information. If its an event registration, we want to scoot them directly to checkout and bypass the middle parts (including payment, that comes later).

I already have code that prevents mixing item types in a cart, but looking to put the pieces together on the pane workflow.

Was able to affect the checkout workflow like so:

http://drupal.org/node/1733562#comment-6353766

But I am not sure how feasible this is (or stable?). I noticed I could not remove or disabled the 'Checkout' or 'Review' step- I only need one. Having both in my case is redundant, but I can't seem to get them to go away.

Take a look at http://drupalcontrib.org/api/drupal/contributions!commerce!modules!check... it may help.

See http://drupal.org/project/commerce_rules_extra

I need something similar for #1873502: Should not be able to apply userpoints as a discount when paying by userpoints where we need to dynamically show/hide checkout panes based on the selected payment processor. An approach based on hook_commerce_checkout_pane_info_alter alone will most likely not work, since payment processors can be changed without a page refresh. For this, we would need to be able to show/hide a checkout pane as part of the ajax event for changing the active payent processor.

The solution in #10 fantastic and flexible. Regarding the original issue raised here, that module clearly solves it.

I second the Commerce Rules Extra module - it works great for our needs: removing the Shipping address pane (from a single checkout page) when a cart only contains digital items.

However, I'd much prefer these additional rules be added into the core Commerce suite. Please consider it! :)

EDIT: It looks like there's actually a bug in the module, at the moment, that disables the checkout pane globally as opposed to the current user. I'm not sure if this is the best solution - I feel like this needs to be better supported in Commerce first, unless I've missed something.

@torgosPizza - Please see http://drupal.org/node/156119, since there is no patch to review setting back to 'active'.

I'd agree with #13 - user based conditions on pane/page checkout states would work better on a more dynamic store. IE one that sells event tickets, digital goods, and physical goods, and stores that have services that don't require upfront payment. Each one of those scenarios has a different workflow.

@torgosPizza. Can you explain bug by adding an issue in Commerce Rules Extra ?
Thanks in advance

@torgosPizza @MarcElbichon
Using Commerce Rules Extra I also didn't see the pane disabled "globally" either. The panes were only disabled for the current user in my testing. IMHO all is well with that solution.

Agree, after further testing it does seem to be just per the current user. IMO this is a fine solution. (Maybe not perfect but it surely works for now.)

Had the same issue. Panes were disabled/enabled according to rules but sometimes they got disabled globally. I'm currently testing http://drupal.org/node/1949780 (included in latest dev).

@spacebox
Can you open an issue in Commerce Rules Extra with a detailled example ?

I had to find a solution to this very quickly. I came up with this kinda hacky solution:

<?php
/**
 * Implements test_plan_commerce_checkout_pane_info_alter()
 */
function test_plan_commerce_checkout_pane_info_alter(&$checkout_panes) {
  if (arg(0) == 'checkout' && isset($_POST['commerce_payment']['payment_method']) && $_POST['commerce_payment']['payment_method'] == 'commerce_paymill|commerce_payment_commerce_paymill') {
    $checkout_panes['customer_profile_billing']['enabled'] = 0;
    $checkout_panes['customer_profile_billing']['page'] = 'disabled';
  }
}
?>

I have the payment method is on the same page. This causes the payment form not being validated properly. Why could this be? Can the form values be retrieved better?

We should be using less Rules, not more. In any case, too late for 1.x