Input don't have class "error" when the input is in error

Yeah, I confirmed this earlier, but I'm not sure there's anything we can do about it in conjunction with the error message trapping we do to put error messages inline with their related checkout panes. I imagine that's what prevents the errors from being detected. Any idea if there's a way to still support the error class without losing this functionality?

Testing your patch out, it does fix the classes but prevents the error messages themselves from showing. We clear out the static cache here with this line to be able to move the error messages inline in our checkout panes. What I think we need to do is perhaps trap the form errors during validation and replay them during form building and trap the status messages then or something... not entirely sure after playing with it for 10 or 15 minutes.

Why is this postponed? I can confirm this problem.

It's pending based on my comments above, basically we need to determine if we can actually fix the classes while preserving our error trapping.

You can. Luckily, _form_set_class() still matches the error correctly. It just expects the #validated property to be set (which isn't done in form rebuilds).

But we can set #validated ourselves without causing damage.

Confirming roderik's patch works.

If you need this fix now, in lieu of hacking contrib in the meantime, this patch works equally well by implementing hook_form_commerce_checkout_form_checkout_alter.

Simply populate $form['#after_build'] for the checkout form with your own copy of the commerce_checkout_form_process_errors and _commerce_checkout_set_validated functions from the patch (watch out for the recursive call in _commerce_checkout_set_validated if renaming!).

Patch at #7 works like charm, thanks!

Confirming that patch at #7 works like a charm also!
Thank you @roderik!

Confirming that @roderik patch fixes the problem.

Works for me as well. Let's get this committed!

Fantastic patch, Roderik. Sorry this took so long to commit!

It doesn't work on date fields :-(

I don't see why it wouldn't... perhaps date is expanding its form elements later than #after_build is actually processing? I actually haven't seen date fields on a checkout form before; how are you getting them in there? Might need a separate follow-up task that's specific to the field type.

I'll investigate further :-)

The inc pages aren't loaded into the registry. And if you are using panels or something that function commerce_checkout_form_process_errors() doesn't exist in the ajax call.

Looking into ways to fix this... opened up a follow-up issue.
#2416921: Fatal error: Call to undefined function commerce_checkout_form_process_errors when displayed through Panels