There are a lot of issues around drupal.org that relate to data integrity when contributed modules update the order object during checkout, for example in a checkout pane or form submission handler.

The problem is that you can't trust that the order in the form state is the latest because other modules may have updated the order outside of the form state.

There is a lot of code around that loads a new version of the order from the order ID of the order in the form state, sometimes then saving that order but not updating the form state order, or to check if it differs from the form state order before making any changes to avoid overwriting anything.

If there isn't already would it be possible to make a policy or something for dealing with this and have 3rd party modules be accountable to that so that we can reliably assume that the order in form state is the latest, or else never rely on form state and always load an order and re-save it every time?

If this policy already exists could you provide a link to the documentation.
It would be good to also provide code examples in the documentation that show the correct way to do things.

Can anyone see scenarios where it would not be feasible to make this reliable?

One example where this has been an ongoing issue is #2026321: Avoid overwriting an already updated order.

Comments

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

I would love to reach some kind of consensus for a "proper" way to handle order flux at checkout. To me it seems like, because of the way the Checkout form is constructed - by loading a base order, and then loading each pane in succession, each of which can then adjust the order data individually and agnostically - can be problematic, especially when introducing new panes that use ajax callbacks for manipulating elements on the checkout page.

We store checkout messages in the $_SESSION variable, is there a reason we can't do something similar at checkout? Some kind of central place for order data to live outside of each individual checkout form.

JMTorres’s picture

JMTorres commented

This issue has major implications with most checkout related modules. Could this potentially be considered "Major" priority rather than "Normal"? The issue has been stagnant for 3 months.

I also have an unreleased module that allows the checkout process ui to be handled through panels. I would like to implement whatever changes need to be made into the routing or form state values in this module as well.

https://github.com/jmtorres/commerce_panels_integration

rooby’s picture

rooby commented

Yeah I'm working on a pretty complex commerce site with almost 50 commerce modules enabled and this issue is a big risk and has caused a few issues along the way.

I ran into another related issue yesterday while working on the checkout:

When the form is processed using ajax the order that gets used when the form is rebuilt is in $form_state['build_info']['args'][0], not $form_state['order'].

This tripped me up for a while with some custom ajax where I was updating $form_state['order'] before the form was processed and then my changes were getting lost in the rebuild.

[edit] fixing sentences so they make sense :)

rszrama’s picture

rszrama commented

@JMTorres I wonder if your code wouldn't be a good candidate to merge into https://www.drupal.org/project/commerce_page_manager?

rooby’s picture

rooby commented

Potentially the documentation that needs to be written for #1804592: During AJAX form submission in checkout, the $order argument passed by the Form API is incorrect. could/should cover this.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Issue tags: +Commerce Sprint