Internal Server Error

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

Code:

---

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:

Quote:

---

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!

Quote:

---

Originally Posted by BlessIsaacola

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)

Quote:

---

Originally Posted by BlessIsaacola

In my case my url looks like this

Code:

---

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.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

Perhaps something is configured wrong in our server

---

Other than permissions problems, this is very unlikely.

Quote:

---

Originally Posted by BlessIsaacola

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

---

Exactly.

Quote:

---

Originally Posted by BlessIsaacola

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

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.

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by BlessIsaacola

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

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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

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!

Quote:

---

Originally Posted by 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!

---

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

Quote:

---

Originally Posted by 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!

---

Zen Cart doesn't use any of those.

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.

Quote:

---

Originally Posted by 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.

---

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

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.

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)

Quote:

---

Originally Posted by RodG

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.

Quote:

---

Originally Posted by 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)

---

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

---

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

PHP Code:

---

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

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?

Quote:

---

Originally Posted by 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?

---

Basically, what I did was I added

Code:

---

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.

Just continuing along the lines of DrBytes approach.suggestions.

Quote:

---

Originally Posted by BlessIsaacola

Basically, what I did was I added

Code:

---

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.

Quote:

---

Originally Posted by BlessIsaacola

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.

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!

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.

Quote:

---

Originally Posted by 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.

---

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*.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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

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

Code:

---

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.

Quote:

---

Originally Posted by 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?

---

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

PHP Code:

---

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

Code:

---

die('it got this far');

---

right after line 40:

Code:

---

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!

Quote:

---

Originally Posted by BlessIsaacola

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

PHP Code:

---

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.

Quote:

---

Originally Posted by BlessIsaacola

If I add

Code:

---

die('it got this far');

---

right after line 40:

Code:

---

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.

Quote:

---

Originally Posted by BlessIsaacola

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

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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?

Quote:

---

Originally Posted by BlessIsaacola

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

Code:

---

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.

Quote:

---

Originally Posted by BlessIsaacola

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

---

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

Quote:

---

Originally Posted by BlessIsaacola

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

Quote:

---

Originally Posted by BlessIsaacola

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

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by BlessIsaacola

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

I lied.

Quote:

---

Originally Posted by BlessIsaacola

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

Code:

---

die('it got this far');

---

right after line 40:

Code:

---

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

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

Quote:

---

Originally Posted by DrByte

[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

In the words of Solomon:

Quote:

---

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

---

sh8t. DrByte is gunna hate me for this.

Quote:

---

Originally Posted by BlessIsaacola

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.

Quote:

---

Originally Posted by RodG

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.

Quote:

---

Originally Posted by 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

Code:

---

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:

Code:

---

  require('includes/application_top.php');

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

  require(DIR_WS_CLASSES . 'currencies.php');

---

Quote:

---

Originally Posted by DrByte

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:

Code:

---

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

Quote:

---

Originally Posted by DrByte

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:

Code:

---

  require('includes/application_top.php');

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

  require(DIR_WS_CLASSES . 'currencies.php');

---

---

This fix introduces another problem...the PayPal detail section and ability to refund an order from the admin side is now gone from the middle section of the screen where it used to be. Please see attached image. Thanks! Attachment 12925

Probably some test stuff we left in there when we were exploring earlier.

I suggest this as a hardening, down somewhere around 600:

Code:

---

      if (is_object($module) && method_exists($module, 'admin_notification')) {

---

That fixed it.
Thanks!