New Checkout Infrastructure

[DivaVocals]

COWOA and other checkout stuff will be getting a refresh shortly once I finish and merge the new checkout flow infrastructure code.

This is the part I'm VERY interested in seeing since there has been an update to COWOA (v2.3) since the v2.2 of COWOA that is currently incorporated into the v1.6 codebase.. Can you share a few details of what this refresh will include??

[wilt]

Hi,

A bit more explanation.

We originally incorporated COWOA into v1.6 based on the module available in our downloads section.

While working up ideas for also incorporating something akin to Fast & Easy Checkout it became obvious that creating alternative checkout flows required hacking quite a bit of core code.

Now that's OK when it's the Development team doing the hacking, as that ends up as release code

However for 3rd party dev's its a PITA.

So based on some ideas from v2 code, we decided to completely redo the way that checkout code happens.

The idea behind the new infrastructure is that the flow from cart to final checkout completion can be defined.

e.g. the inital checkout step is determined programtically based on an observer chain. e.g. observers are fired and based on outcomes the initial page is determined. An example would be cowoa. e.g. if cowoa is enabled and no addresss details exist then a guest page is displayed.

Steps beyond the initial page can also be determined programaticaly, using a sort of simplified state machine.

we've include lots of helpers including a breadcrumb builder that responds to the much more dynamic nature of the checkout flow.

Use cases for this include for example.

expedited checkout: e.g. Fast & Easy
Membership checkouts: Where some membership information is required.
Cowoa of course.
Download Checkouts. Where you might only collect email info & pay by Paypal. e.g. no shipping/billing required.
etc

HTH

[RodG]

Use cases for this include for example.

expedited checkout: e.g. Fast & Easy
Membership checkouts: Where some membership information is required.
Cowoa of course.
Download Checkouts. Where you might only collect email info & pay by Paypal. e.g. no shipping/billing required.
etc

HTH

Will this have any impact on the shipping modules themselves? If so, in what way?

Cheers
Rod

[wilt]

Will this have any impact on the shipping modules themselves? If so, in what way?

Cheers
Rod

It shouldn't have any impact on existing modules. DrByte and Ajeh have updated the core shipping modules code to allow for some more fine grained control using observer/notifier stuff, and we will document that soon.

[badarac]

Will this allow a change in the order of checkout steps? One of my most requested changes is forcing the shipping method to be reselected if a discount coupon causes the order total to drop below a certain level. Will I be able to have the payment step execute before the shipping method is selected?

[DivaVocals]

Hi,

A bit more explanation.

We originally incorporated COWOA into v1.6 based on the module available in our downloads section.

While working up ideas for also incorporating something akin to Fast & Easy Checkout it became obvious that creating alternative checkout flows required hacking quite a bit of core code.

Now that's OK when it's the Development team doing the hacking, as that ends up as release code

However for 3rd party dev's its a PITA.

So based on some ideas from v2 code, we decided to completely redo the way that checkout code happens.

The idea behind the new infrastructure is that the flow from cart to final checkout completion can be defined.

e.g. the inital checkout step is determined programtically based on an observer chain. e.g. observers are fired and based on outcomes the initial page is determined. An example would be cowoa. e.g. if cowoa is enabled and no addresss details exist then a guest page is displayed.

Steps beyond the initial page can also be determined programaticaly, using a sort of simplified state machine.

we've include lots of helpers including a breadcrumb builder that responds to the much more dynamic nature of the checkout flow.

Use cases for this include for example.

expedited checkout: e.g. Fast & Easy
Membership checkouts: Where some membership information is required.
Cowoa of course.
Download Checkouts. Where you might only collect email info & pay by Paypal. e.g. no shipping/billing required.
etc

HTH

Yes that does help a bit.. Do you guys intend to use any part of the latest version of COWOA (v2.3) in the codebase?? I ask because in v2.2 of COWOA there are usability inconsistencies in the user interface (check out steps in particular), unclear on-screen messages, and page layouts that need some improvements to remove ambiguity. The changes in v2.3 of COWOA addressed many of these usability issues. Was hoping to see some or all of this included in the COWOA code included in Zen Cart v1.6.

[wilt]

I guess I should qualify my previous post.

In core code we will be supporting 3 checkout flows.

The legacy checkout flow e.g. checkout shipping -> checkout payment -> checkout confirmation -> checkout success

Cowoa checkout

Expedited Checkout e.g. something akin to Fast & Easy

The new infrastucture will allow you to do something like

Hit Checkout Shipping, choose shipping method. Divert to a new flow based on the shipping method chosen.

To do that, then yes you would need to re write the shipping module and use some observer/notifier hooks etc.

However for the inbuilt core stuff, we currently don't expect that any shipping modules will need to be updated.

[wilt]

Yes that does help a bit.. Do you guys intend to use any part of the latest version of COWOA (v2.3) in the codebase?? I ask because in v2.2 of COWOA there are usability inconsistencies in the user interface (check out steps in particular), unclear on-screen messages, and page layouts that need some improvements to remove ambiguity. The changes in v2.3 of COWOA addressed many of these usability issues. Was hoping to see some or all of this included in the COWOA code included in Zen Cart v1.6.

I guess the simple answer to that question is no.

We can't really use COWOA module code in v1.6 as it was not written for the new infrastucture. However we have taken some lessons from updates to COWOA recently, and used those ideas. There has been work done on say guests being able to view historic order info without logging in, and changes to how the session is destroyed on checkout completion etc.

Things like the order email changes necessary for COWOA are now completely driven by observer/notifiers

[wilt]

Will this allow a change in the order of checkout steps? One of my most requested changes is forcing the shipping method to be reselected if a discount coupon causes the order total to drop below a certain level. Will I be able to have the payment step execute before the shipping method is selected?

In theory, Yes. As long as someone writes the code

[lankeeyankee]

In regards to the shipping aspect, I strongly urge you to look at the Advanced Shipper module. The code is open source but the instructions are not. But it allows for the most fine-grained control of shipping that you could ever want. It's simply amazing and I really think it should be in the core, or at least take the features it offers and rewrite it to fit in your new framework. If you have never checked it out I can send you the open source code files (but not the instructions) or you can buy a copy to be able to get the instructions. I use it exclusively and it is excellent, in fact the core wouldn't even need any other shipping modules since you can do multiple flat rate, multiple zone, Priority Mail, UPS, FedEx. The flexibility is phenomenal.