Internal Server Error

[BlessIsaacola]

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

I did not find anything useful in the error_log. I am hoping once I understand DrByte's instruction and start the test that hopefully it will reveal something. I compared the files on the server to the ones in my downloaded 1.5.1 (just like I did before upgrade) and I don't see anything strange like file missing or different (that shouldn't be different). It's definitely a mystery but at least I am glad it's not affecting customer's ability to checkout.

[BlessIsaacola]

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)

Thank you DrByte. I got as far as line 353 without triggering the 500 internal server error. The code around that line looks like this with my addition for testing purpose:

<?php
  require(DIR_WS_INCLUDES . 'header.php');
die('it got this far');
?>
</div>

After this point is where thing starts to break. Whatever is triggering my 500 internal server error lines somewhere here:

<!-- body //-->
<table border="0" width="100%" cellspacing="2" cellpadding="2">
<!-- body_text //-->

<?php if ($action == '') { ?>
<!-- search -->
  <tr>
    <td width="100%" valign="top"><table border="0" width="100%" cellspacing="0" cellpadding="2">
      <tr>
        <td><table border="0" width="100%" cellspacing="0" cellpadding="0">
         <tr><?php echo zen_draw_form('search', FILENAME_ORDERS, '', 'get', '', true); ?>
            <td width="65%" class="pageHeading" align="right"><?php echo zen_draw_separator('pixel_trans.gif', 1, HEADING_IMAGE_HEIGHT); ?></td>
            <td colspan="2" class="smallText" align="right">
<?php
// show reset search
  if ((isset($_GET['search']) && zen_not_null($_GET['search'])) or $_GET['cID'] !='') {
    echo '<a href="' . zen_href_link(FILENAME_ORDERS, '', 'NONSSL') . '">' . zen_image_button('button_reset.gif', IMAGE_RESET) . '</a><br />';
  }
?>
<?php
  echo HEADING_TITLE_SEARCH_DETAIL . ' ' . zen_draw_input_field('search') . zen_hide_session_id();
  if (isset($_GET['search']) && zen_not_null($_GET['search'])) {
    $keywords = zen_db_input(zen_db_prepare_input($_GET['search']));
    echo '<br/ >' . TEXT_INFO_SEARCH_DETAIL_FILTER . $keywords;
  }
?>

Not exactly sure looking at the above line what's causing the issue but at least I know line 1-353 is NOT my problem. Any insight as to what may be my issue in the above code? I don't even see anything that have to do with Gift Certificate which is the scenario I am able to use to trigger the internal server error.

[DrByte]

Hmmm ... But ... $action == 'edit' from the URL you quoted in your first post.
So that suggests to me that you're not testing this with having clicked Edit. Right?

[BlessIsaacola]

Hmmm ... But ... $action == 'edit' from the URL you quoted in your first post.
So that suggests to me that you're not testing this with having clicked Edit. Right?

Basically, what I did was I added

die('it got this far');

to a line and then upload to the server but making sure that I am on the order list page before replacing the file on the server. Then I click on the order in question which triggers the Internal Server Error when I got to the section in orders.php. I started the testing from the top moving down. I test both good and bad order to make sure the logic is still working. I know it's VERY strange but I don't get it. I even looked at the code from 1.3.9h to compare to orders.php from 1.5.1 and the code for that section is the same.

By the way if images will help I can take a screen capture to show you what it looks like on my screen. As I move the code, the page is rendering what should have been rendered up until the point when it breaks.

[RodG]

Just continuing along the lines of DrBytes approach.suggestions.

Basically, what I did was I added

die('it got this far');

to a line and then upload to the server

That's the correct thing to do, although, I will state when using this method of debugging, I tend to make the edits on the 'live' file and forgo the uploading of the edited file. It tends to be a lot quicker (especially if you keep the editor open during debugging)

Oh, by 'live site', I generally mean a live test site rather than an actual live store, but if the actual live store is broken I don't have many qualms against working on the live store, but backing up files before making any edits are essential.

Another thing I tend to do (especially where I don't have a clue what I'm actually looking for), is to add more than one 'die' command at a time. Typically at the start of any of the 'functions', and quite often just after any 'if' commands that may be relevant, then I run my test(s) and watch where it 'dies', then I commend out that 'die' statement and test again.... This process is repeated until the Internal server triggers before the 'die' commands. The 'last' die command commented out before the crash is where thing fall over.

Keep in mind that the 'die' command, when used this way, will stop the processing when the code is doing what it *should*, and not where the problem you are trying to find is.

If we use your example:
-------------------------------------
<?php
require(DIR_WS_INCLUDES . 'header.php');
die('it got this far');
?>
</div>
------------------------------------------

The code will stop/die only if the require(DIR_WS_INCLUDES . 'header.php'); command is *successful*. If this command fails (due to the Internal Server error) then the 'die' command wouldn't be triggered... the server will be 'dead' before it gets that far, and if this was the case, we can conclude that the cause of the problem will be something to do with the require(DIR_WS_INCLUDES . 'header.php');

In your case, it appears that this 'die' command is being triggered at this point of time, therefore we can conclude that the problem has nothing to do with require(DIR_WS_INCLUDES . 'header.php'); so you can remove this particular 'die' command, because the problem is occurring further down the code.

On many occasions, stepping through and working with the 'die' command can be somewhat frustrating, so another method I often use is to replace the 'die' commands with 'print' or 'echo' commands.. Using your example again, by changing

<?php
require(DIR_WS_INCLUDES . 'header.php');
die('it got this far');
?>

to
<?php
require(DIR_WS_INCLUDES . 'header.php');
echo 'it got this far';
?>

Will cause the program to output this text somewhere on screen (probably messsing up the format of the rest of the page), but by having several of these 'echos' in 'relevant' parts of the code you can often perform just a single test, and by checking the various 'I got this far' outputs it is often quite easy to find where the program fails.

[QUOTE=BlessIsaacola;1215011] I even looked at the code from 1.3.9h to compare to orders.php from 1.5.1 and the code for that section is the same./QUOTE]

Hmmm, keep in mind that the orders.php is merely a good/suggested starting point. The actual problem could by caused by other code that this file is calling/using.

Again, using your example of the edit to the order.php file
<?php
require(DIR_WS_INCLUDES . 'header.php');
die('it got this far');
?>

If you did get an Internal Server error before the die('it got this far');command is triggered, it is telling us that the problem is likely to be found in the header.php file. We are simply using the orders.php file at the moment as a logical starting point.

By the way if images will help I can take a screen capture to show you what it looks like on my screen. As I move the code, the page is rendering what should have been rendered up until the point when it breaks.

In this case I'd say the screenshots will probably be of no help at all. At best, it will simply confirm what you've told us, but this isn't in dispute.
On the other hand, without knowing exactly what the screenshots actually show, it is impossible to say if they'll be helpful or not.

If you think they will show something that would possibly provide a clue, then you'd be foolish to not let us see them. Your call.

Meanwhile, back to the 'die' method of debugging. If I were you, I'd be adding these commands to places like

after the line that reads:
if (($action == 'edit') && ($order_exists == true)) {

The code will almost certainly get this far without a problem (based on the fault symptoms) but this would be a closer 'staring point' than the one you chose. The logic being is that the problem is only triggered when doing an edit ($action == 'edit') and where an order exists. This 'if' line is the one that ensures these conditions are both met.
If you place the 'die' command after this line, and it *doesn't* get triggered then we need to have a serious rethink about what is going on because there will be more to this than meets the eye.

On reflection, this little block of code seems like a good place for several 'die' (or 'echo') commands at the same time:

EG:

<?php
if (($action == 'edit') && ($order_exists == true)) {
echo "edit valid order" ;
$order = new order($oID);
echo "new order class created ok" ;
if ($order->info['payment_module_code']) {
echo "we have payment module code defined" ;

if (file_exists(DIR_FS_CATALOG_MODULES . 'payment/' . $order->info['payment_module_code'] . '.php')) {
echo "Payment module exists" ;
require(DIR_FS_CATALOG_MODULES . 'payment/' . $order->info['payment_module_code'] . '.php');
echo "Payment module loaded" ;
require(DIR_FS_CATALOG_LANGUAGES . $_SESSION['language'] . '/modules/payment/' . $order->info['payment_module_code'] . '.php');
$module = new $order->info['payment_module_code'];
echo $module->admin_notification($oID); // this line already exists, it just needs to be uncommented.
}
}
die('End of this set of tests') ;
?>

At the moment, this is a bit of an overkill. You could just as easily use the 1st and last 'echo' commands only, and assume that if it gets this far then all is ok with this part of code. However, if it doesn't get this far, those other 'echos' will tell you where to look next... If you see
"edit valid order"
"new order class created ok"
"we have payment module code defined"
"Payment module exists"
Followed by the dreaded 'Internal server error' you can safely assume the problem is caused trying to process:
require(DIR_FS_CATALOG_MODULES . 'payment/' . $order->info['payment_module_code'] . '.php');

IOW, as illogical as it may seem, this will be telling us that the problem is actually something to do with the payment module(s).......

Hmm, perhaps not so illogical after all, because you DID state the problem is only with a particular payment didn't you......

Although not at all intended, it does seem quite possible I've inadvertently pointed you closer to the cause (or a possible cause) than I could possibly imagined when I started writing this post.

Either way, I do think this is a better starting point than where you are currently at.

Do be a little careful about using 'echos' for debugging rather than 'die'. Quite often the 'echos' will be flashed on screen for just a brief instant before they can get overwritten/hidden, which makes them useless. If you think this is occurring then you need to 'die' the processing before this occurs.

die('it got this far');
and
echo "it got this far" ; die ;

... both have a similar effect. It is a mostly matter of preference. I tend to prefer the
echo "it got this far" ; die ;
because it makes it easy to comment out the 'die', but still keep the 'echo'.

Happy hunting.

Cheers
Rod.

[BlessIsaacola]

Thank you! You have my head spinning that's for sure. I have inserted DrByte's code all over the places in previous tests and everything was fine until I got to around line 353 of orders.php.

Because this problems ONLY happens when a gift certificate is involved, I am not even sure that's it's totally a payment mod issue. The fact that I cannot duplicate the problem in my test environment makes this even more frustrating. I will give it another try when I can perhaps wrap my head around some of what you suggested.

Thanks!

[BlessIsaacola]

For what it is worth, PARTIAL gift certificate works just fine. The only time this error is triggered is if a customer use gift certificate to pay for an entire order.

[RodG]

Thank you! You have my head spinning that's for sure. I have inserted DrByte's code all over the places in previous tests and everything was fine until I got to around line 353 of orders.php.

This is/was

-------------------------------------
<?php
require(DIR_WS_INCLUDES . 'header.php');
die('it got this far');
?>
</div>
------------------------------------------

READ CAREFULLY:
If the code 'died' at this point, with the 'it got this far' displayed on screen, then everything IS OK UP TO THIS POINT.

It sounds to me that it is getting to this point, and you are considering this to be where the fault *is* rather than where it *isn't*.

I am not even sure that's it's totally a payment mod issue.

NEITHER ARE WE.

We are GUESSING just as much as you are. The difference is that we are making educated guesses based on logic (and experience).
Your guesses (eg, where to place the 'die' commands) seem to be without logic.
require(DIR_WS_INCLUDES . 'header.php');
is a piece of code used with almost every aspect of ZenCart. I would NEVER have placed my 'die' command after the require(DIR_WS_INCLUDES . 'header.php');
simply because this is such a generic and commonly used piece of code, if there WAS something amiss with the header.php file (which is what your 'die' test is meant to prove/disprove, then we could logically expect much more serious problems with the store, rather than something that is taking a rather 'unique' set of circumstances to trigger.

The fact that I cannot duplicate the problem in my test environment makes this even more frustrating.

Hhhhm, if you can't duplicate the problem in your test environment then I hope you aren't trying to debug in this test environment, because doing so will be futile. You'll never find the problem if it doesn't exist with the code you are testing with.

This is also why we can't to the testing/checking required for you. Our systems don't exhibit the same problem, and unless we can replicate it, all we can do is try to guide you in the ways that *we* would do things if *we* did have the problem setup to work with.

I will give it another try when I can perhaps wrap my head around some of what you suggested.

It's not rocket science. It is just a matter of following the program flow until you hit the problem. Keeping in mind that computers don't call things at random.
EVERYTHING is performed in a very specific sequence of events that are controlled by 'if/then' statements.
The 'trick' to finding a *speedy* solution is in trying to find a good place to start following the trail for any given problem.

You *could* start your 'die' commands in the 'index.php' file if you wanted (this is what gets the whole ball rolling) and eventually you'll be led to the cause of the problem. Things can be sped up considerably if you start the debugging closer to the source of the problem though, and this is where experience and logic plays a big role. We can guide you along the way to increase your experience levels, and we can even use our own logic to determine where a good place to start will be, but going that next step in following the program flow is a logical process that you need to do for yourself.

My previous post wasn't designed to a step by step guide as to what you need to do, or where to look, so please don't treat it is some sort of 'bible'. It was designed to provide you with examples of the things you need to do and consider. This is why I opted to use 'your' code portion for my initial examples.

The later examples and suggestions I gave are little more than the approach *I* would take if I had this exact same problem. Another developer/coder may decide that even this is the 'wrong' place to start the debugging, and they could well be correct. Where *I* chose to start could easily lead to a dead end, in which case, I'd need to try to find another 'logical' starting place.

The bottom line is that we can't hold your hand with this one. We can provide you with the methods and techniques, but you are the only one in a position to follow them through until the *cause* is found. Once the cause has been found we should be able to give you additional information as to how you need to fix it, but that's a whole new ballgame.

Remember. If you reach/trigger the 'die' commands then everything is OK up to that point. You need to remove the 'die' command to let the processing continue past that point with a new 'die' command further down the code.... FOLLOW THE PROGRAM FLOW!

Cheers
Rod

[BlessIsaacola]

I really appreciate you attempt to help but I find some of your posts condescending. Perhaps if you actually read what I am posting you would insult less. Why would I be testing against an environment that doesn't have the problem I am trying to solve. I've been around long enough to know that wouldn't make sense. 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.

I am NOT asking you to hold my hand so don't. 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. Until DrByte provided the die statement I was making no progress. Since you're so knowledgeable you could actually have provided this solution (instead of jumping on it) but you were simply just "talking" until DrByte injected an actionable approach. 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.

[BlessIsaacola]

Hmmm ... But ... $action == 'edit' from the URL you quoted in your first post.
So that suggests to me that you're not testing this with having clicked Edit. Right?

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']));
  } 

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.
Thanks!