Order Display Problems after upgrading to PHP 5.2.5

[studio3d]

I am unable to display orders at all in my store since upgrading to PHP 5.2.5. I am using Zen Cart 1.3.7.1, Database Patch Level: 1.3.7.1, and MySQL 4.1.20. Is this issue fixed in 1.3.8 or is it worth the upgrade. I have a customer presentation coming up in two days and my Zen store is now broken. Orders complete, but you get an empty list when viewing Orders via the admin or by order history logged in as a customer. There are no visible errors in the PHP log... Any one have any suggestions?

[DrByte]

What you're experiencing shouldn't be related only to PHP 5.2.5. It is more likely a database issue.

A few questions:
- what payment modules are enabled in Admin->modules->payment?
- is your store in down-for-maintenance mode?
- what order-total modules are enabled in Admin->modules->order totals?
- what order statuses are listed in Admin->Localization->Order Status?

[studio3d]

I am using Zen Cart as a class registration system where the products are classes and there are no enabled payment methods. The client also wishes that no prices be displayed, so most everything in the Order Total modules is disabled with the exception of the ot_total line.

What is required to be enabled to display the orders in Admin / Customers / Orders? They also do not display in the customer-side "My Account" sections. If I recall correctly, everything was working until we upgraded PHP. When customers checkout, they get an order confirmation listing their classes and I installed the Sales Report plugin that is able to display the orders, but I need the orders to show up for the customers and under Admin/ Customers / Orders.

Specific answers to your questions:
- what payment modules are enabled in Admin->modules->payment? None
- is your store in down-for-maintenance mode? (checked) No.
- what order-total modules are enabled in Admin->modules->order totals? (only ot_total)
- what order statuses are listed in Admin->Localization->Order Status? ot_code_fee, ot_coupon, ot_group_pricing, ot_gv, ot_loworderfee, ot_shipping, ot_subtotal, ot_tax, and ot_total.

Any suggestions on what I could try to fix this before my presentation tomorrow?

[DrByte]

If you have no enabled payment methods, checkout should not be able to proceed.
Have you altered the code somehow to bypass the normal checks?
It is normally the payment module that sets the order status on order completion.

[studio3d]

The order statuses for the orders in question are set to 2. Is there any reason they are not being displayed? If I enable a payment module will already completed orders display in the admin section? If not, would simply modifying the order status allow them to display?

[DrByte]

You're great at answering questions with questions instead of answers ... which suggests that you prefer to figure it out by yourself.

The SQL joins several tables to find the appropriate valid output to display. If the dependencies do not exist, the data will not display.
ie: the orders, orders_products, orders_total, orders_status, orders_status_history, etc tables must be in sync.

If you've altered the code to force certain values without keeping all appropriate related tables in sync, you'll naturally not get any data back.
Here's a reference to the tables used in handling order information: http://www.zen-cart.com/wiki/index.p...#Order_History

[studio3d]

Let me apologize first of all for my frankness. I've been working 24/7 to get this presentation ready and it's coming down to the wire. I greatly appreciate your help.

As far as I know, I have not subverted the payment process in the checkout procedure. Because the client desired not to display a payment method of any type, I hid the payment methods box with CSS and ensured that something acceptable was hidden but default selected.

The true culprit was that during a previous meeting the client wanted to change the order status types. We removed the default one and added a few. That was the problem. Removing the default caused a critical part of the query you mentioned above to fail.

I found an instance of the order history query in includes/modules/pages/account_history/header_php.php.

if ($orders_total > 0) {
$history_query_raw = "SELECT o.orders_id, o.date_purchased, o.delivery_name,
o.billing_name, ot.text as order_total, s.orders_status_name
FROM " . TABLE_ORDERS . " o, " . TABLE_ORDERS_TOTAL . " ot, " . TABLE_ORDERS_STATUS . " s
WHERE o.customers_id = :customersID
AND o.orders_id = ot.orders_id
AND ot.class = 'ot_total'
AND o.orders_status = s.orders_status_id
AND s.language_id = :languagesID
ORDER BY orders_id DESC";

It was the (o.orders_status = s.orders_status_id) conditional that caused it to return an empty set from my database. It turns out the order status on the orders was set to a default value of "2", but there was no corresponding status defined in the orders_status table.

Simply defining an order status for ID 2 brought everything back online. The order history for client side accounts as well as the listing of orders and order administration are now all fully functional again.

I suppose this means it might be good to have a check / warning system for this potential problem display in the admin under Localization / Order Status.

Once again, thanks for all your help. I truly appreciate it. I hope that if someone else runs into this problem, the information posted here will help shed some light on the matter.