Internal Server Error

[BlessIsaacola]

I am not sure what exactly causing the problem I am experiencing since upgrading to ZC 1.5.1. I must also say the problem does NOT happen with a clean install just my upgraded version.

Here is the scenario:
Find a customer with gift certificate in their account (or email a gift certificate to a customer)
Once the gift certificate is available, order an item that's less than the gift certificate value
During checkout pay entirely for the whole order with gift certificate so the customer doesn't pay anything but the GC value.
Now go to the order page and try to edit that order by clicking on "edit" this is when I get the error.

In my case my url looks like this

https://www.clevershoppers.com/MYADMINFOLDER/orders.php?origin=index&page=1&oID=172400&action=edit

but the page returns a 500 internal server error with the following:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [email protected] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Unfortunately, I do not have anything in the Zen Cart log or Apache log to help me troubleshoot what's causing this.

My order.php is exactly the same as the one in my cleaning install that doesn't have the problem.

I will greatly appreciate any help to trap this error or what's causing it. I am sure this probably NOT an issue related to ZC but I need help to get to the bottom of it. Perhaps something is configured wrong in our server (but then it should have my clean install as well). Probably a mod that I am not aware of? Help please!

[RodG]

Here is the scenario:
Find a customer with gift certificate in their account......................

Is that the only scenario that shows the problem?

What happens if you try to edit any of the other orders? (those without gift certs)

In my case my url looks like this

https://www.clevershoppers.com/MYADMINFOLDER/orders.php?origin=index&page=1&oID=172400&action=edit

This is typical of what it should look like. This is why it is important to know if the problem exists with all edits, or whether it is just particular specific orders.

but the page returns a 500 internal server error

More often than not, this is a permissions problem, but your 'observation' that it relates to only particular orders tends to suggest that this probably isn't the case this time.

Unfortunately, I do not have anything in the Zen Cart log or Apache log to help me troubleshoot what's causing this.

The 500 internal server error messages that you see are rather generic and devoid of any any information that could aid a hacker from gaining control of a system. To find the exact cause of the error you will need to contact your hosting provider. Their logs will provide the information you need.

Perhaps something is configured wrong in our server

Other than permissions problems, this is very unlikely.

(but then it should have my clean install as well).

Exactly.

Probably a mod that I am not aware of? Help please!

Hhhmm, please don't take this the wrong way, but if you do have a mod that you are unaware of, then what makes you think that we can 'magically' tell you which one it is?

Having said that, at the moment I do tend to agree with your line of thought, in that it *is* a module that you've installed that is causing the problem. It is one of the few things that will differentiate between a fresh install and an upgrade. Alas, this doesn't bring me/us any closer to determine what that mod may be.

If your observation that it only occurs with orders that have gift certificates is true, then the 'obvious' place to start looking would be towards any mods that you have installed that somehow affect these certificate/coupon. (I can't think of any of the top of my head though).

Enlisting the help of your host to identify the source/cause of the error from their logs will be the least stressful way of finding the cause (and solution), because without this there isn't much option than resort to trial and error (disabling/removing mods, etc) until the problem goes away.

Simply put, I/we are currently as much in the dark as you are, in fact you even have the advantage over us, because you should know more about the what mods you've installed... we can only guess and speculate.

Sorry I can't be of any more help at this stage.

Cheers
Rod

[BlessIsaacola]

Thanks for taking the time to thorough respond to my post. I am sorry I didn't explicitly state that this problem ONLY occurs with orders that are paid for FULLY using a gift certificate. All other edits work just fine as well as accessing invoices, packing slip and such. We currently do not have any mod that affects the checkout flow. We used to have Rewards Points and Google Checkout Mod but those are no longer on our site but still have their tables and configurations intact in the database.

The host are claiming that they are not seeing anything more. We are on a dedicated server and I have root access and I did check all the logs out there and I don't see anything myself that is useful (at the moment). Still digging.

I know there's a tool (or code) I can use to printing what's happening but I don't remember how to implement this at the moment. I am basically hoping there's some debugging/sniffer I can activate.

Again, thanks for your help.

[RodG]

Thanks for taking the time to thorough respond to my post. I am sorry I didn't explicitly state that this problem ONLY occurs with orders that are paid for FULLY using a gift certificate. All other edits work just fine as well as accessing invoices, packing slip and such.

In your defence, you did explicitly state the problem. I just needed for you to verify that it was indeed only with the orders paying fully by a gift certificate.

Unfortunately, your confirmation that all other edits work fine has actually deepened the mystery.

We used to have Rewards Points and Google Checkout Mod but those are no longer on our site but still have their tables and configurations intact in the database.

Of these two, I'd be looking more towards the reward points module.... but its little more than a passing thought at this stage.

As for the tables and configurations in the database (for these modules), they *won't* be the cause of the problem, and removing them can actually make things worse (It depends on whether you still have any php files laying around that actually references these tables).

The host are claiming that they are not seeing anything more. We are on a dedicated server and I have root access and I did check all the logs out there and I don't see anything myself that is useful (at the moment). Still digging.

Oh, OK. I didn't realize you had a VPS. This means that you have the exact same information available to you as your host does. (Their claims are true).

I've no idea what log files you've actually looked at, but the ones you should be looking for are often found as:
/var/log/httpd/error_log or
/var/log/apache(2)/error_log or something similar

Don't forget the .php error logs either. The location is user defined and can generally be found in the php.ini file.

I know there's a tool (or code) I can use to printing what's happening but I don't remember how to implement this at the moment. I am basically hoping there's some debugging/sniffer I can activate.

Although there are tools and methods you can use for debugging, none of them will tell you as much and as succinctly as the error logs. That is the sole point of their existence.

Depending on your current settings and configurations you may even need to increase the 'log level' (the amount of data that gets logged) in order to get the information needed. For a 500 error though this is generally not required.

Cheers
Rod

[BlessIsaacola]

By the following functions are disabled on our server: dl,show_source,system,shell_exec,passthru,popen,proc_open Do you see any problem with any of them? Thanks!

[RodG]

By the following functions are disabled on our server: dl,show_source,system,shell_exec,passthru,popen,proc_open Do you see any problem with any of them? Thanks!

Those seem to be typical settings for a server with moderate security (meaning that there may be times where one or more are too restrictive for the task at hand).

I don't see them being relevant to this issue though.

Still no luck with the error logs?

Cheers
Rod

I'm heading off to bed. Nothing more from me until late tomorrow. Hopefully you'll have found the cause by then :)

[DrByte]

By the following functions are disabled on our server: dl,show_source,system,shell_exec,passthru,popen,proc_open Do you see any problem with any of them? Thanks!

Zen Cart doesn't use any of those.

[DrByte]

While it's kinda ghetto, I'd probably start by editing the orders.php file and inserting a bunch of die() statements between the various statements from lines 1-55. Basically to see where the code dies. Put in a die('it got this far'); statement, reload the page in the browser, and see if the message displays. If it does, move the die statement down a line and repeat.

If it croaks before application_top returns, then it's probably something in the init system that's failing. If it croaks when loading and instantiating the orders class then it could be something in there. And so on.

[BlessIsaacola]

While it's kinda ghetto, I'd probably start by editing the orders.php file and inserting a bunch of die() statements between the various statements from lines 1-55. Basically to see where the code dies. Put in a die('it got this far'); statement, reload the page in the browser, and see if the message displays. If it does, move the die statement down a line and repeat.

If it croaks before application_top returns, then it's probably something in the init system that's failing. If it croaks when loading and instantiating the orders class then it could be something in there. And so on.

DrByte, not to sound stupid...you want me to put exactly this code:

die('it got this far');

or something else? For some reason, I have a feeling 'it got this far' needs to be replaced with something.

[DrByte]

I meant literally exactly that.

The die() function will halt execution and display whatever message you put in between the brackets.
So, since *you* know what line you put the die() message on, *you* will know exactly how far the code got.
And if you get a blank page (500 error) you will know that the code didn't finish all the way to the line where you put the die() statement, and then you can narrow things down to wherever the actual problem is occurring. And then fix it.

You could also replace it with die('I got to ' . __LINE__ . ' in ' . __FILE__); but the line number will only be meaningful to *you* since only *you* know what changes you've made to various lines in your file. (my point here is that telling "us" what line number may not be useful since you're changing the code in order to do these tests)