Suddenly A Very Strange Checkout Problem - hangs up, since 2 days ago

This site has been running fine for months. Up until 2 days ago.

Now with an item in the cart we go to check out and hit the go to paypal payments pro button it hangs up.
I get a url that looks like this:

.../index.php?main_page=checkout_shipping&zenid=vgpcknni6rle4sgfogjih0d0u2

but I get a blank page. No error code. Checking the logs just sends us to line 1034 of orders.php, which doesn't help me any.

We restored the site from a backup that was made before the last two successful orders and before we found this issue. Still no improvement.

Where do I go from here?

EricRas:

No error code. Checking the logs just sends us to line 1034 of orders.php, which doesn't help me any.
So also failing to post the actual log details doesn't help us any when trying to help you.

Sorry, I thought I'd given you everything out of the log that was necessary, but I guess not.

The log reads:

[13-Sep-2013 12:53:19] PHP Fatal error: Cannot redeclare class order in
/.../.../.../.../cardecals-4u.com/includes/classes/order.php on line 1054"

In a nutshell that error message is PHP telling you: "Hey, I've already loaded a class named 'order'. Why are you asking me to load another class named 'order' from '/includes/classes/order.php'? I do not allow you to load multiple classes with the same name (and namespace). Until you stop this behavior (trying to load a class with the same name twice) I am not going to continue."

Could be some corruption on your server (you mentioned recently doing a restore?) or a modification (plugin, template, etc) was made which is causing the issue. Without more information it will be difficult for anyone here to attempt to help you troubleshoot further... At the minimum knowing in what way your Zen Cart installation differs from a clean install and providing the full contents of the debug log files (not excerpts).

Note: Please use the "#" button to wrap the full contents of your debug log in a "code" block to ensure all text and formatting is preserved. Feel free to continue removing the home directory, but remember to leave everything after the document root for your domain. Do not remove other information from the debug log such as the "PHP Stack trace" (this information can be useful to others trying to help you).

It sure sounds like a corrupted file; why is the order class (in /includes/classes/order.php) redefining itself? Possibly having a bad day?

Line 1054 of my unmodified version of v1.5.1's order.php file is the ending brace -- } -- that ends the class definition.

lat9:

It sure sounds like a corrupted file; why is the order class (in /includes/classes/order.php) redefining itself? Possibly having a bad day?

Line 1054 of my unmodified version of v1.5.1's order.php file is the ending brace -- } -- that ends the class definition.

line 1054 of my version of v1.5.1's order.php file is also the ending brace

The restore was after we found the problem.

I don't know why it's trying to load the class twice, and that was the full contents of the log files.

EricRas:

The restore was after we found the problem. ...
Was the restore from a backup you made? Or an automated one from the provider? Do you have older backups you can compare to the current site?

EricRas:

... I don't know why it's trying to load the class twice, and that was the full contents of the log files.

Normally you see something like the following in the debug logs (myDEBUG-xxxx.log). On some hosting providers this information may be in the server error log or a php error log. In local WAMP installations, sometimes the information is logged to the "Event Viewer" -> "Windows Logs" -> "Applications"

[17-Sep-2013 13:26:27 UTC] PHP Fatal error:  Cannot redeclare class order in /includes/classes/order.php on line 1054
[17-Sep-2013 13:26:27 UTC] PHP Stack trace:
[17-Sep-2013 13:26:27 UTC] PHP   1. {main}() /index.php:0
[17-Sep-2013 13:26:27 UTC] PHP   2. require() /index.php:97
[17-Sep-2013 13:26:27 UTC] PHP   3. require() /includes/templates/custom/common/tpl_main_page.php:46
[17-Sep-2013 13:26:27 UTC] PHP   4. require() /includes/modules/pages/index/main_template_vars.php:217

In the case of the above generated myDEBUG-xxxx.log example an error was purposely introduced to show what a Zen Cart debug file looks like. The specific error introduced was multiple "require DIR_FS_CATALOG . DIR_WS_CLASSES . 'order.php';" lines in "/includes/templates/custom/templates/tpl_index_default.php" on lines 15 & 16. This file is loaded by line 46 of "/includes/templates/custom/common/tpl_main_page.php". As you can see having the entire PHP Stack trace as well as knowing the contents of the files in question (especially if they have been modified from the stock Zen Cart files) is necessary to trace the error.

If you cannot gain access to the above information (and the hosting provider is unable or unwilling to help you), you can try following the instructions for diagnosing obscure issues...

We seem to have corrected these problems. I finally woke up and found the info about renaming old files. We had some renamed to something like

xxx_old.php, or xxx_orig.php. Those were all renamed to something like xxx_php.old or xxx_php.orig

The issues magically went away.

Thanks

After reinstalling the usps module everything works fine!!