Upgrade Problems. All help is appreciated 1.5.1 to 1.5.4

Hey there everyone.
**
Basic Information:**
Current Version: 1.5.1
PHP Version: 5.4.3
Database Patch Level 1.5.1

I'm upgrading our shopping cart from 1.5.1 to 1.5.4

It's got quite a few customers and products so all of that needs to be brought over. The current version has quite a few mods. Here's a link to the Mod List.

I was hoping to do a fresh install, transfer the old customers and products, and then start anew on the mods. It's proving to be a bit more of a PITA than I was hoping..

I've tried a fresh install -> import old database -> patch database to 1.5.4 -> transfer over theme files (Pure_Green_Free)

At that point I'd think it would work but when ever I hit the checkout button to test it out, it brings me to a 500 error page.

I wouldn't mind just installing a fresh copy and just transferring over the product information/attributes and customer information and start brand new with the rest.

Any idea guys? I'm trying to avoid the whole comparing the files side by side.

CHerbalist:

it brings me to a 500 error page.

This is a server error. The most common cause of this error is due to folder permissions - typically when set to '777'. If you have any set like this, change them to '775' to see if the server 500 error goes away.

There are many other causes of the server 500 error, but the folder permissions are always the 1st thing I suspect/check.

Cheers
RodG

You could also check in your store's /logs folder. Many times the "Server 500" also has created a myDEBUG*.log file that will point you in the direction of the solution.

lat9:

You could also check in your store's /logs folder. Many times the "Server 500" also has created a myDEBUG*.log file that will point you in the direction of the solution.

Hmmm, no. Seriously, just no. Zencart cannot log a server 500 error for two very good reasons.
I really shouldn't need to tell you what those reasons are.

I'll give you a hint about though, one has to do with security, the other is a logical side effect of the first. ;-)

Cheers
RodG

RodG:

Hmmm, no. Seriously, just no. Zencart cannot log a server 500 error for two very good reasons.
I really shouldn't need to tell you what those reasons are.

I'll give you a hint about though, one has to do with security, the other is a logical side effect of the first. ;-)

Cheers
RodG
I'm just saying what I've seen in the past, possibly based on an AJAX interface that died for a SQL error.

lat9:

I'm just saying what I've seen in the past, possibly based on an AJAX interface that died for a SQL error.

Again, no, just no. I don't know what you are thinking of, but you will never, ever have seen zencart (or any other Web application) log a server 500 error (which is why these errors can often be impossible to isolate without help from the host)

Cheers
RodG

RodG:

Again, no, just no. I don't know what you are thinking of, but you will never, ever have seen zencart (or any other Web application) log a server 500 error (which is why these errors can often be impossible to isolate without help from the host)

Cheers
RodG
Rod, I disagree.

I do agree that a Server 500 error itself will not be logged as a 500 error.

But its VERY common for a server-side fatal PHP error to get logged when triggered, but then the manifestation of that fatal error is that PHP then tells the webserver to trip a 500 error. IMO this is even more true for PHP-FPM than just PHP-SAPI.

So, @lat9's correct in advising to check the debug logs for the potential existence of logged PHP errors.

DrByte:

I do agree that a Server 500 error itself will not be logged as a 500 error.

That is all I was saying, :-)

DrByte:

But its VERY common for a server-side fatal PHP error to get logged when triggered, but then the manifestation of that fatal error is that PHP then tells the webserver to trip a 500 error. IMO this is even more true for PHP-FPM than just PHP-SAPI..

I can add a few 'buts' to this too, and I reckon we could end up with a good debate over technicalities, details and probabilities. Let's no go there though (for everyone's sanity) <g>

I somehow feel obliged to share some of you own words from several years ago though 25 Feb 2012

"500 errors are triggered by your SERVER, before Zen Cart even has a chance to do anything.
Thus, you need to investigate the problem with your hosting company"

And from the ZenCart FAQ file:
"THAT is why the fastest way to find the solution to a "500 Internal Server Error" problem is to look it up in the server's logs. If that means logging a ticket with your hosting company, DO IT".

It seems to me that based on this thread/discussion, the FAQ file should be updated to read "Check Zencarts error logs first, and if that doesn't help, THEN contact the hosting company because clearly, contacting the host 1st, then checking the zencart log files isn't going to be the fastest way. <evil grin>

DrByte:

So, @lat9's correct in advising to check the debug logs for the potential existence of logged PHP errors.

Aye. In fact I owe an apology here, because it was clearly stated

"created a myDEBUG*.log file that will point you in the direction of the solution".

I somehow missed the 'point you in the direction', and jumped to the conclusion that it was the error 500 itself that would be logged. I humbly apologise.

Cheers
RodG

Point taken. FAQ updated.

cherbalist, did you solved this issue?

Woah. Appreciate the help guys.

I took a look into the logs files. Cleared them out and recreated the problem. This log popped up:

[16-Feb-2016 13:10:12 America/New_York] PHP Warning:  include_once(includes/modules/shipping/ups.php): failed to open stream: No such file or directory in /home/cheryls/public_html/testsh/includes/classes/shipping.php on line 58
[16-Feb-2016 13:10:12 America/New_York] PHP Warning:  include_once(): Failed opening 'includes/modules/shipping/ups.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/cheryls/public_html/testsh/includes/classes/shipping.php on line 58
[16-Feb-2016 13:10:12 America/New_York] PHP Fatal error:  Class 'ups' not found in /home/cheryls/public_html/testsh/includes/classes/shipping.php on line 59

EDIT: I'm going to try and reinstall my shipping modules and see if that helps at all since the problem seems to be coming from shipping.php

Shipping modules must be installed in pairs: the module and its corresponding language file. If you're missing one of those, you'll get the kind of message you quoted.

Yup. Got it all taken care of. Had a few more problems pop up but I was able to fix them by looking in the logs.

Thanks for all the help everyone!