Checkout - how do I skip all the steps?

[SHK]

I've been going through the code for the checkout flow, and I noticed that it could easily be modified to skip step 1 and step 3.
In a situation where a store only allows one address per customer, and only has one (or dosn't let the customer pick) shipping option,
these seem pointless. Step 1 simply because no information is altered, and Step 3 because frankly it might be sort of pointless in any case,
and certainly if you would only be confirming one page of input, Step 2. I could see people forgetting what options were selected on Step 1,
but not really Step 2. ANYHOW...

I would very much like some input from the ZC experts. What problems would I face? What additional alterations would I have to make
in order to not break the basic structure of zen cart, and its various underlying processes?

Below are the alterations I've made so far. This works, and there are no obvious problems that I can se. Everything looks like it should.
I've not done extensive testing, nor checked the database logs from notifier trace. That would be my next step.

Any hints or pointers would be greatly appreciated.

Added above row 239 in /includes/modules/pages/checkout_shipping/header_php.php

//
// I did not know the usual content_type so I negated virtual instead.
//
  if ($order->content_type != 'virtual') {
    zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
  } 

Commented out row 34 in /includes/modules/pages/checkout_payment/header_php.php

// if no shipping method has been selected, redirect the customer to the shipping method selection page
if (!$_SESSION['shipping']) {
// zen_redirect(zen_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL'));
} 

Commented out row 41 in /includes/modules/pages/checkout_confirmation/header_php.php

// if no shipping method has been selected, redirect the customer to the shipping method selection page
if (!$_SESSION['shipping']) {
//  zen_redirect(zen_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL'));
} 

Added above row 171 in /includes/modules/pages/checkout_confirmation/header_php.php

// if payment method has been selected, redirect the customer to the checkout process page
 if ($_SESSION['payment']) {
  zen_redirect(zen_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL'));
} 

[lat9]

The one shipping option that your store provides, is it a flat rate regardless of the products in the customer's cart or does the rate vary with cart-content?

[SHK]

The one shipping option that your store provides, is it a flat rate regardless of the products in the customer's cart or does the rate vary with cart-content?

Flat rate. We might use ot_shipping to give free shipping over a certain cart value.

I actually have several shipping modules on my test site right now, with restrictions on weight/product type etc,
and the cheapest allowed module does get selected.

[mc12345678]

More related to the original question than the current train of shipping, regarding the one address per customer, may see that a single person may create multiple accounts to support shipping to multiple locations, but that I thhink is more dependent on the products offered. Also consideration of a difference between shipping and billing addresses. Again, something that is dependent on the business and products involved, though it does appear that the billing address can be changed in step 2, but would be auto-populated with the shipping address.

All of that is from a "functional" perspective not from a code perspective.

[lat9]

Flat rate. We might use ot_shipping to give free shipping over a certain cart value.

I actually have several shipping modules on my test site right now, with restrictions on weight/product type etc,
and the cheapest allowed module does get selected.

You just need to make sure that the checkout_shipping pages processing sets $_SESSION['shipping'] to the array of values associated with your flat-rate module and that the $_SESSION['sendto'] is set to the customer's default address id. I'd think twice (at least) about commenting out the checkout_shipping redirects, given that your modified version should set the above two values to a "proper" setting and then redirect to the checkout_payment page.

An order's content type is either 'physical', 'virtual', or 'mixed'. The "normal" processing on the checkout_shipping page bypasses the data gathering if the order is all 'virtual' (i.e. all products that don't actually ship anywhere).

Are you planning on using coupons? Their "normal" processing is to gather information on the checkout_payment page to display a confirmation of the discount on the checkout_confirmation page (or redirect back to checkout_payment if there was an issue with the coupon, like it wasn't valid). I believe, but do not know, that the same is true when using gift vouchers -- the reduction doesn't show until the checkout_confirmation page.

[SHK]

More related to the original question than the current train of shipping, regarding the one address per customer, may see that a single person may create multiple accounts to support shipping to multiple locations, but that I thhink is more dependent on the products offered. Also consideration of a difference between shipping and billing addresses. Again, something that is dependent on the business and products involved, though it does appear that the billing address can be changed in step 2, but would be auto-populated with the shipping address.

All of that is from a "functional" perspective not from a code perspective.

Right. In our case, very few customers use more than one address, and sometimes only by mistake, Also, our invoice-provider requires that the customers uses only one address, the one listed in the pubic residential records.

You just need to make sure that the checkout_shipping pages processing sets $_SESSION['shipping'] to the array of values associated with your flat-rate module and that the $_SESSION['sendto'] is set to the customer's default address id. I'd think twice (at least) about commenting out the checkout_shipping redirects, given that your modified version should set the above two values to a "proper" setting and then redirect to the checkout_payment page.

Right you are. I reverted the commented out redirects.
I believe $_SESSION['sendto' ] was already handled in the original code. It also seems to set the $_SESSION['shipping'] correctly.
This started to work properly when I moved the if ($order->content_type != 'virtual') { redirect to the bottom of the page.

An order's content type is either 'physical', 'virtual', or 'mixed'. The "normal" processing on the checkout_shipping page bypasses the data gathering if the order is all 'virtual' (i.e. all products that don't actually ship anywhere).

Thanks. Changed.

Are you planning on using coupons? Their "normal" processing is to gather information on the checkout_payment page to display a confirmation of the discount on the checkout_confirmation page (or redirect back to checkout_payment if there was an issue with the coupon, like it wasn't valid). I believe, but do not know, that the same is true when using gift vouchers -- the reduction doesn't show until the checkout_confirmation page.

Good point. We never had much success with coupons since our customers couldnt understand when and where to enter them. I mostly use links that set the code for them. In any case, if I enter the code and press enter, the payment page is reloaded and the rebate shown. If I dont hit enter, it will still work, but as you said without letting the customers know. The ot_shipping module works fine too, the shipping is reported as zero. Granted, I may have to style this a bit so that the customers notices the rebates given.

Thanks for all the help so far!