New Checkout Infrastructure

wilt:

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??

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 :laugh:

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

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

wilt:

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

RodG:

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.

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?

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 :laugh:

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

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.

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.

DivaVocals:

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

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?

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

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.

wilt:

In theory, Yes. As long as someone writes the code :smile:
I'm looking forward to playing with that.

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.

For what my opinion is worth, I second this suggestion fully.

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.

I use this and I totally agree....

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.My vote, as well.

wilt:

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

Right.. I understand that the new checkout is BASED on COWOA.. However the version integrated now leaves out little details like the consistency of the order steps between the guest checkout and the full checkout. They are incorrect in the COWOA that has been integrated.. Then there are other things like the fact that some of the text that appears next to the continue button in each step of the checkout is incorrect as well..

Now while these may seem minor, these are things that clients and customers notice.. Which is more to the point I was trying to make.. I would hope that usability factors are not lost in the code improvements..

DivaVocals:

Right.. I understand that the new checkout is BASED on COWOA.. However the version integrated now leaves out little details like the consistency of the order steps between the guest checkout and the full checkout. They are incorrect in the COWOA that has been integrated.. Then there are other things like the fact that some of the text that appears next to the continue button in each step of the checkout is incorrect as well..

Now while these may seem minor, these are things that clients and customers notice.. Which is more to the point I was trying to make.. I would hope that usability factors are not lost in the code improvements..

I think wilt was saying that we'll do a compare of your old and your new cowoa code to see what things you've done that haven't already been integrated, and consider including them if they fit with the way the new code works. Afterward if there are glaring problems you can of course submit improvement suggestions.

DrByte:

I think wilt was saying that we'll do a compare of your old and your new cowoa code to see what things you've done that haven't already been integrated, and consider including them if they fit with the way the new code works. Afterward if there are glaring problems you can of course submit improvement suggestions.

Fair enough then.. :smile:Functionally the two versions are basically the same.. The other changes were designed to correct UI inconsistencies.. (the bulk of my concerns/suggestions)

Off topic

In regards to the shipping aspect, I strongly urge you to look at the Advanced Shipper module.:yes:

...but since someone has dared to stick their neck out and state the obvious...I'll fifth that.

If it was in the core now, no-one would bother with the other piece-meal methods. Its a comprehensive, well-written single solution to an infinite range of problems. Including it would really improve Zen Cart and it would be a fitting tribute to that exceptional Zen Cart contributor who produced by far the best code outside the development team (imho).

Time for a new 1.6+ wish-list thread I think....

torvista:

If it was in the core now, no-one would bother with the other piece-meal methods. **Its a comprehensive, well-written single solution to an infinite range of problems. Including it would really improve Zen Cart and [U]it would be a fitting tribute to that exceptional Zen Cart contributor who produced by far the best code outside the development team /U.

*Time for a new 1.6+ wish-list thread I think....:yes:
nods in ENTHUSIASTIC agreement with this

DivaVocals:

:yes:
nods in ENTHUSIASTIC agreement with this*

Yeah, what they said. Man I miss Conor