Internal Server Error

[DrByte]

DrByte, can you please help me understand what this section in orders.php is doing

if (isset($_POST['oID'])) {
    $oID = zen_db_prepare_input(trim($_POST['oID']));
  } elseif (isset($_GET['oID'])) {
    $oID = zen_db_prepare_input(trim($_GET['oID']));
  } 

In english it means: if a <form> has been submitted and contains a value for the oID field, then set $oID to the sanitized and trimmed value of that field. Else, if &oID=xx was passed via the URL, then set $oID to the sanitized and trimmed value of that URL parameter.

If I add

die('it got this far');

right after line 40:

if (isset($_POST['oID'])) {

Then it triggers the internal server error message.

I believe you're telling me that you stuck your die statement inside the first half of that "if" statement, and since your oID is actually a GET parameter (via the URL) and not part of a <form> post, your die statement is just being ignored, thus allowing the code to continue on to whatever is triggering the 500 error in the first place.

I'd move your die statement down below the whole block and carry on with your investigation process.

[RodG]

I really appreciate you attempt to help but I find some of your posts condescending.

You *really* shouldn't have taken and made this 'personal'. I'm now about to be moderated, and it may be best if you don't read any further.....

Why would I be testing against an environment that doesn't have the problem I am trying to solve.

I don't know, but I do know that you wouldn't be the 1st idiot I've met that has done this, and you won't the the last.

Perhaps if you actually read what I am posting you would insult less

You stated "The fact that I cannot duplicate the problem in my test environment makes this even more frustrating".
Until statement you've never made any other mention of a test environment. Is there any reason why I shouldn't assume that you *may* be trying to do the debugging in this same 'new' environment?

I'll wager that If I didn't ask for or make this clarification then someone else would have. If we can't ask questions and clarification without you taking insult then what hope is there of helping you?

As for being condescending, I can accept that with ease. I *am* far superior to you when it comes to debugging. If that wasn't the case, I wouldn't be in a position to try to help.
I am also a very arrogant bustard, and proud of it.

You shouldn't let my 'flaws' affect your further education and knowledge though. That is only punishing yourself.

I've been around long enough to know that wouldn't make sense.

How are we supposed to know that, especially when the problem you are trying to solve should be a *trivial* matter? It is only hard for *us* because we don't have access to your servers, and since this will be piff easy to identify with the access that *you* have, and the fact that you still can't isolate the problem is telling me that regardless how long you've been around, you don't even have a basic clue where to begin or how to proceed. Why should we credit you with even basic computer skills when you don't seem to show any?

Perhaps if you actually read post #12 and paid close attention you would have known EVERYTHING worked including

require(DIR_WS_INCLUDES . 'header.php');

which means I actually see the header loaded on my screen..

Yup, read all that, and commented/replied appropriately. You somehow came to a conclusion that "Whatever is triggering my 500 internal server error lines somewhere here".
Perhaps I shouldn't have been so subtle in my reply, so time for the sledgehammer. YOU HAVE COME TO THIS CONCLUSION BASED ON A FALSE PREMISE DUE TO YOUR LACK OF UNDERSTANDING OF HOW AND WHERE TO USE THE 'DIE' COMMANDS.

I will even go as far to say that the cause or your problem is most definitely *not* in the portion of code you specified. It doesn't take a genius to see that.

To me this is a clear indication that in spite of "being around long enough to know that (debugging on a test server without the problem) wouldn't make sense", that you still have the debugging skills of a complete novice. If you can make one simple mistake or erroneous deduction, you can just as easily make both.

I am NOT asking you to hold my hand so don't.

Someone is going to have too. This much is obvious.

I can definitely do without your post on my problem because in less words, DrByte actually provided an actionable item and I am getting closer using his approach.

Now if you take any personal issues you have with the way I word things out of the equation, you'll note that DrByte only provided you with the basic principles, and *his* suggested starting place. You followed that advice and came to a wrong conclusion (post#12), but based on that same post I was able to deduce *why* you came to this wrong conclusion (and even attempted to explain it to you.... even though it *shouldn't* have needed to be explained in the 1st place.

Somehow I unintentionally caused you offence with this.. <hhhmpphh>. Not to worry, because now you've made it 'personal' I've opted to keep it that way, and rather than just thinking you are a clueless idiot that probably has no right to be running a VPS in the first place (security reasons) I'm quite happy to forgo the usual niceties and call it as I really see it. You chose to be offended, I'm now just giving you a much better reason :)

Until DrByte provided the die statement I was making no progress. Since you're so knowledgeable you could actually have provided this solution.

DrByte hasn't provided with with a solution at all. Not even close. He has (somewhat reluctantly, I assume) provided you with details/instructions of one of the most common debugging methods. His 'starting point' is/was almost certainly further away from finding the actual cause than my amended/suggested die point(s). This wasn't to be known at the time he made his suggestion though, which makes his starting point just as valid as mine.

All I did was follow the program flow from his starting point (and your initial findings) to what I feel would be the next logical place to insert the 'dies'. This is something that YOU SHOULD HAVE BEEN ABLE TO DO FOR YOURSELF if you weren't such an stubborn ignoramus (I warned you the insults were going to fly). If I'm going to be considered an ######, then I feel obliged to be the best ###### as I can be. I try to excel in everything I do :)

instead of jumping on it) but you were simply just "talking" until DrByte injected an actionable approach.

<cough> <clears throat>

It is VERY RARE that DrByte and I actually disagree with each other, mainly because when it comes to computers and programs there isn't much room for personal opinions (something you need to learn), but in this case, other than for training purposes, I think he has done you a great disservice by leading you down this particular path.

It is NOT a path I would have chosen for you because anyone that needs to be taught these techniques from scratch has a very steep learning curve, and it is NOT the best method to find the cause of your problem.

I think DrByte gave you more credit than you deserve by thinking that you could actually take his initial guide and running with it until you found the cause.

What do you think he meant with his opening words "While it's kinda ghetto" ?

Like me, he knows full well that this is not the best of methods of finding your problem, but in the absence of anything else to go by, there aren't too many other choices.

I feel like you're actually crowding this thread which makes it harder for people who really want to help to follow the thread. I can definitely do without the epistle.

The epistles are necessary. You have shown that you can't take a short guide as supplied by the Doc and run with it. It was my *hopes* that since the Dr had started on you this path a more detailed explanation would be beneficial to you. Apparently I was wrong. The steep leaning curve seems a little more than you can handle..... You say I seem condescending, when the fact is, I was giving you far more credit than you deserve.

Do you want to know why I think DrByte has done you a disservice by suggesting this technique? (probably not, but I'm going to tell you anyway).

Its quite simple really. There IS a far easier way to *instantly* identify what is causing the 500 Server errors without using the suggested debugging techniques, but you keep ignoring it... It relates to my posts that you consider to be just "talking", and it all comes back to the log files.

Yes, I know you state/claim that the log files don't provide any clues, and this being the case, you should be fixing this problem before trying to find the cause of the 500 Server Errors.

The fact is, all servers can and will provide a means to log these errors. This is an *essential* function that all sysadmins rely on. How else is a server admin supposed to be able to identify such errors unless they experience it for themselves? Simply put, if you are running a VPS and you don't have these logs enabled then you are a total fckwit.

SO, the fastest and simplest way for you to identify the cause, is to just fix the logging and then use the logs to identify the cause. I can *guarantee* that this will be a faster solution than anything else you care to try. If you don't do this, you are missing out of one of the main benefits of running a VPS in the 1st place.

Not only will this logging provide you with a quick and easy method to identify the cause of your *current* problem, it will also provide you with information about any/many other problems that you aren't even aware of.

This is going to be my last post on this subject. I'm not going to waste my time trying to teach you how to enable the required logging because you've already tried to insult me, so I think I am going to have great pleasure out of sitting here and watching DrByte lead you down a very murky road where you don't need to be in the first place.
Don't worry, he'll get you there in the end, he is exceptionally talented, knows his stuff (at least as much, and probably more than I). He also has better people skills than I do (I reckon he's not as old an cynical as I am). <g>

It is just going to take a lot longer and a lot more work than necessary... T

This could be fun :)

Bye
Rod

[RodG]

I lied.

That's Lines 40-44 in that file. If I add

die('it got this far');

right after line 40:

if (isset($_POST['oID'])) {

Then it triggers the internal server error message. I am not a programmer so I don't really understand what that section of the code is doing. I started adding the die statement line by line again and I was able to trigger the internal server error after adding it after line 40.

ROFL. I don't believe that you still don't get it. You are still approaching this all wrong, and you are asking irrelevant questions.

At this rate, this thread will still be going for another few weeks, and unless DrByte gives up out of sheer frustration he is going to end up trying to explain the workings of every piece of irrelevant code that you place a 'die' command.

I knew this would be a fun thread to watch, but I didn't expect the jokes to start so soon :)

LOL.

Rod

[DrByte]

[moderator hat on]
Rod,
Time to shut up.

[RodG]

[moderator hat on]
Rod,
Time to shut up.

That is/was my plan/intention anyway, but thanks for not disappointing me. I understand and appreciate the position I placed you in (sorry about that)

BlessIsaacola is now in your capable hands (and I don't envy you a single bit). :)

Cheers
Rod

[BlessIsaacola]

In the words of Solomon:

Do not answer a fool according to his folly, Lest you also be like him.

[RodG]

sh8t. DrByte is gunna hate me for this.

In the words of Solomon:[Do not answer a fool according to his folly, Lest you also be like him.

Did you think it clever to post this *knowing* that I've been officially told to 'shut up'. Talk about kicking a person when he's down.

It is good advice. The problem is, I didn't know I was answering a fool when I 1st responded. Now look at me, just as much as a fool as you.. Err, probably moreso, I *know* I being foolish posting this. At least you can be ignorant about your own foolishness.

[DrByte]

I've been officially told to 'shut up'.
I *know* I being foolish posting this.

Rod,
Enough with the bullying and sarcasm and other nonsense, both here and in other threads.

[DrByte]

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: 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!

Turns out it's an issue with M1 MagneticOne code not cleaning up properly after itself and thus tainting the variable scope.

So, if you're actually using the M1 stuff, change your /admin/orders.php file, around line 11, by adding the code shown here:

  require('includes/application_top.php');

// added to reset garbage leftover by MagneticOne code:
  if (isset($module)) unset($module);

  require(DIR_WS_CLASSES . 'currencies.php');

[BlessIsaacola]

Turns out it's an issue with M1 MagneticOne code not cleaning up properly after itself and thus tainting the variable scope.

So, if you're actually using the M1 stuff, change your /admin/orders.php file, around line 11, by adding the code shown here:

  require('includes/application_top.php');

// added to reset garbage leftover by MagneticOne code:
  if (isset($module)) unset($module);

  require(DIR_WS_CLASSES . 'currencies.php');

Thank you so much DrByte for solving the puzzle and helping us return our site back to normal. I am going to reach out to MagneticOne support for them to read this post so they can clean up their mess. I will try to alert other Zen Cart users on their end as well just in case there's someone else experiencing the same problem (or perhaps not even aware there's a problem).