Orders_total table has no records for otherwise valid orders

[byakudan]

I am upgrading to v1.5.5f from v1.5.1. I am using PayPal Standard because I want the customer to be able to use a credit card WITHOUT having to create a PP account. I am testing live, not sandbox.

I have added a $1 test product. My test account placed two orders, both of which were successfully processed thru PayPal, and then successfully refunded thru PayPal. The data returned from PayPal to Admin was complete and correct.

The orders do not show up on the Accounts Orders or Order History pages. They do show up correctly and completely in the Admin Orders page.

On the database, the data for both orders is in the orders, orders_product, and orders_status_history tables.
There are no entries for either order in the orders_total table. This caused the select statement to return zero records when attempting to display the account orders because there was no match on order number.

I manually inserted a class "ot_total" record into orders_total for each order. This was sufficient to allow the orders to display properly on the Account Orders and show-all-orders pages. So those pages do work.

I have been unable to find the file that inserts the data into the orders_total table so I cannot determine why that is not being updated. The amounts appear on the order pages prior to going to PayPal, so the data is somewhere at that time.

I am running in Down for Maintenance mode. Is that my problem? What file does the actual insert into the orders_total table and where is the maintenance flag being tested, if it is the cause? Where else should I look if it is not?

I have spent nearly 120 hours on this "simple upgrade" so far, and this is one of two major issues left before I can take the site live again. A quick and detailed response would be appreciated.

Thanks.

[byakudan]

I thought I had posted this eight hours or so earlier today, but it never appeared as a new post on the forum, so I am reposting. My apologies if this is a duplicate.
--------------------------
I am upgrading to v1.5.5f from v1.5.1. I am working with a clone of the Responsive-Classic template. I am using PayPal Standard because I want the customer to be able to use a credit card WITHOUT having to create a PP account. I am testing live, not sandbox, but site is Down for Maintenance.

I have added a $1 test product. My test account placed two orders, both of which were successfully processed thru PayPal, and then successfully refunded thru PayPal. The data returned from PayPal to Admin was complete and correct.

The orders do not show up on the Accounts Orders or Order History pages. They do show up correctly and completely in the Admin Orders page.

On the database, the data for both orders is in the orders, orders_product, and orders_status_history tables.
There are no entries for either order in the orders_total table. This caused the select statement to return zero records when attempting to display the account orders because there was no match on order number.

I manually inserted a class "ot_total" record into orders_total for each order. This was sufficient to allow the orders to display properly on the Account Orders and show-all-orders pages. So those pages do work.

I have been unable to find the file that inserts the data into the orders_total table so I cannot determine why that is not being updated. The amounts appear on the order pages prior to going to PayPal, so the data is somewhere at that time.

I am running in Down for Maintenance mode. Is that my problem? What file does the actual insert into the orders_total table and where is the maintenance flag being tested, if it is the cause? Where else should I look if it is not?

I have spent nearly 120 hours on this "simple upgrade" so far, and this is one of two major issues left before I can take the site live again. A quick and detailed response would be appreciated.

Thanks.

[swguy]

I am upgrading to v1.5.5f from v1.5.1...

I am running in Down for Maintenance mode. Is that my problem?

That will cause problems. Take your store out of Maintenance mode for final tests.

[lat9]

There have been a lot of changes to Zen Cart over the past 6 years (1.5.1 was released in September of 2012)!

A couple of things you can check (given that you've chosen to use that older PayPal Standard payment method):

1. Are there any myDEBUG*.log files present in the store's /logs directory? They might identify where the issue is occurring.
2. You could turn on the debug option in the payment method; that way, any communications between PayPal and your site will be captured in various .log files (also in the /logs directory).

I'm not familiar with the inner-workings of PayPal Standard, but I'm wondering if the fact that your site is in maintenance mode is "interfering" with that payment method's post-back/update.

[mc12345678]

As to the inner workings and where/when the order_totals table is to be updated, assuming that the paypal module otherwise handles everything correctly and calls the order class' create function (with an array of order totals) then it is at or about line 686:

zen_db_perform(TABLE_ORDERS_TOTAL, $sql_data_array);

Where the order_totals module data is to be stored in a normal checkout. This depends on the array of order total modules having at least one element to store and that array is passed as the first parameter to the method.

[byakudan]

Thanks to each of you who replied to this!

swguy - running a transaction live instead of "down for maintenance" did in fact solve the problem with the orders_total table. I'm not sure why only that table is affected, because the other transactions under DFM went completely thru PayPal and were recorded in the other order-related tables. One would think that a transaction would either totally work under DFM, or totally NOT work under DFM. Half-and-half is frustrating.

lat9 - I was running in debug mode on PP Standard, and so I went thru the logs. Found an unrelated error being reported so I fixed that. Thanks for the reminder about why debug is useful!

mc12345678 - I located the file and read thru it. I still cannot see why only those records aren't generated in DFM mode, but running live fixed it.


I still have two more PayPal/Order related issues so I will list them here and perhaps you all can suggest the fixes?

1. PayPal is returning me to MYSITE.COM/index.php?main_page=checkout_payment. However I get a 403 - Forbidden error - you do not have permission to access /index.php. (This also happened with the live test.) On my PP account, the return page is set to ?main_page=checkout_success but it is ignoring that.

The "checkout_payment" page is only Step 2 of the ordering process. The actual page with the "confirm" button that calls PayPal is checkout_confirmation, which is Step 3, but it isn't returning to that page either.

What page do I need to supply to PayPal, since it doesn't seem to be sending to my choice, or the one it came from? And why a 403-Forbidden error if it is going somewhere legitimate, even if not correct? Is this actually caused by a permissions error in .htaccess or something similar?

2. The successful order is causing TWO emails to be sent to the customer, with slightly differing header and footer information, but the identical body information. Any ideas why, and how to fix this? Frankly, I am tired of searching thru the entire program over and over trying to track down things like this.

Thanks.

[mc12345678]

Not yet sure of the two email issue, but the return page is relatively easy. When looking at the setup options for paypal, it should list the return page similar to index.php?main_page=checkout_process

This way ZC is able to determine what to do next. If it is a success, then it would likely move on to checkout_success. If it is back to starting again it would be likely checkout_shipping...

[byakudan]

mc12345678 - Thank you for the clarification on how the pages relate when returning from PayPal. I made the suggested changes so the URLs are correct.

GOOD NEWS!!! I finally tracked down the 403-forbidden error on the return, and it was "operator error". The debugging was essentially a matter of eliminating possible permission problems. I had set up my /public_html/.htaccess file to prevent hotlinking of images. I had added php to the list of extensions for some reason. When I removed that from the list, PayPal linked back to the various payment pages with no problems.

Now I just need a fix for the double emails - I will continue to work on that but if you have a suggestion, I'd be grateful!

Thanks for your patience!!

[byakudan]

Double emails problem is solved. Operator induced. When I finally thought to check the headers, one is to the customer (myself) and one is the admin copy (also to myself, same domain, different name). Since they both showed up in the same email folder I didn't think to look at who they were addressed to.

I can now take my updated shop live again at last.

I appreciate the quick responses I received on the forum to my questions. Thank you! I hope this thread in turn helps someone else resolve a difficulty.