Hard to explain or reproduce, but when form error messages are generated in checkout panes, they are stored in form_state. So if you submit the form, you get the messages over the desired pane. If, however, you edit some field that triggers an ajax request on the same pane, the messages should go away but they don't.

In my setup, pane has options for "new address", "existing address", "same address". Selecting one triggers ajax that renders a form with certain fields. If you select "new address", an addressfield form is rendered, with some required fields. I click submit, wich fails because required fields are empty. The messages show up in checkout pane properly. Then if I click "same address", the addressfield fields are gone after the ajax, but the error messages for the required fields get rendered again.

I found the bug is caused by Commerce and this simple patch prevents it.

CommentFileSizeAuthor
commerce-checkout_pane_error_messages.patch869 bytesfranz
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

rszrama CreditAttribution: rszrama commented
Status: Needs review » Closed (won't fix)

Thanks for the report and patch, franz. I was actually able to reproduce the issue fairly easily, but honestly, I'm not sure it's one that can be solved in the core of Drupal Commerce. The problem is that we don't know for certain that the form rebuild for the pane actually removes the elements that were previously responsible for the error messages. Additionally, in my test, error messages were still appearing even with your patch.

I tested this two ways:

  1. On a clean install of Kickstart 1.x, attempt to submit the initial checkout page without filling in a billing address. You'll get a bunch of error messages for missing required fields. Change the country to trigger an AJAX refresh, and the error messages will persist. To be honest, in this instance, it seems like required functionality.
  2. On a clean install of Kickstart 1.x install another payment method module. Enable it alongside the core example payment method module. Attempt to submit the review checkout page without filling in a name for the example payment method, triggering the error message asking for a name (or put in a single character if you want to test it with an error message other than the regular required element error message). Change to the other payment method, and the error message will persist.

In either case, your patch didn't remove the messages shown for elements no longer on the page. I wonder if it's related to the error messages still being in $form_state['storage']['errors'] - i.e. perhaps since those are still in the form state, the error messages are being regenerated even though you're unsetting them.

Anyways, as I said above, I don't think we can just issue a blanket unset like this in the checkout form builder function. It seems instead like something a checkout pane itself ought to do if necessary. In your case, it sounds like you are using a custom checkout pane. My recommendation would be to make the required form state changes in your checkout pane builder function instead where you can ensure that the elements are no longer present on the form.