ajax error during checkout

earthfriendly,
i think you are making good progress. i am not sure what the developers had in mind when using ajax. i do not know how it would work when using paypal express, but it might be worth wild to try changing the value of PADSS_AJAX_CHECKOUT which is accessed from:

../admin/configuration.php?gID=1

just to see if you could complete the checkout process without errors.

in addition, there is a way to step through your javascript calls to see where the problem might be. when using the developer tools, if you click on sources, you can then load any of your javascript files (*.js); and insert breakpoints by clicking on the line number. you can then step through various sections to further isolate the problem call.

best.

@earth-friendly, I'll echo carlwhat's comment: Good investigative work.

It almost sounds like the function collectCardDateOnSite isn't being called (thus, the null response). You could try adding some "did I get here?" type entries into that function (present in /includes/classes/ajax/zcAjaxPayment.php).

If you use the PHP error_log function, e.g. error_log ('Got here');, you'll see the results (if that code's executed) in a debug-log file in your /logs folder.

I'm *guessing *that the issue has arisen due to a missing/uninitialized variable in the PHP processing path. As such, install my Report All Errors plugin, get your store to the point where it is just about to give you the AJAX error, go to your admin and switch the RAE on and then cause the store to generate the error.

You'll be "rewarded" with a massive debug-log file that contains every nit-pick within the PHP processing path -- missing variables, doubly-defined constants, etc.. Hopefully, one of those nit-picks will identify the source of your issue.

Thanks very much, carlwhat and lat9, for your suggestions. Sorry I didn't follow up sooner. I was staying up til all hours working on this, and the sleep deprivation finally got to me!
lat9, I installed your Report All Errors contribution. Thanks very much! Wow, that does produce a lot of stuff!
I found one odd thing, that showed up when I used cod, but didn't show up when I used authorizenet_aim.

Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 352
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 352
Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 353
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 353

These 2 lines in includes/classes/order.php are in red below:

$this->info = array('order_status' => DEFAULT_ORDERS_STATUS_ID,
                        'currency' => $_SESSION['currency'],
                        'currency_value' => $currencies->currencies[$_SESSION['currency']]['value'],
                        'payment_method' => $GLOBALS[$class]->title,
                        'payment_module_code' => $GLOBALS[$class]->code,
...

So if I interpret this correctly, $class is the current payment method, 'cod', and $GLOBALS['cod'] should be set, but isn't.
I'm not positive that this is THE error that is ultimately causing the Ajax error I am seeing, but I don't see a similar error showing up when I use authorizenet_aim.
I'm not sure where in the code $GLOBALS['cod'] should be getting set. And I need to get to sleep.
If anything jumps out at someone based on what I've said, please let me know. Otherwise, I'll try to keep plugging away.

Thanks to everyone for your help with this!

The use of the PHP $GLOBALS variable is a short-hand way of indicating that the variable in-question is out-of-scope. So the order-class's use indicates that somewhere in all the data generated for the current page, there's a variable named $class (the contents of the $class variable, actually) that's an object and that class's title and code variables are being used.

For example, the cod payment method, when instantiated, creates a class-object named $cod. So, somewhere in the datapool, there should be a $cod variable.

Does the AJAX error you're chasing appear regardless of the payment method you're currently using, or is it specific to the authorize_net-AIM payment method?

earth-friendly:

Also, as I said above, when I used the cod and paypal payment methods, I got the ajax error when I clicked to go to the order confirmation page. But when I used the authorizenet_aim payment method, I was able to checkout completely without any errors. I looked at the code for the 3 payment modules, and I didn't see anything obvious that would cause the errors in the 2 modules, but not in the third.

lat9, according to earth-friendly, authorizenet_aim is the only payment method where the ajax does work. cod and paypal do not.

earth-friendly:

...

Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 352
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 352
Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 353
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 353

> 
> These 2 lines in includes/classes/order.php are in red below:
> ```
$this->info = array('order_status' => DEFAULT_ORDERS_STATUS_ID,
                        'currency' => $_SESSION['currency'],
                        'currency_value' => $currencies->currencies[$_SESSION['currency']]['value'],
                        'payment_method' => $GLOBALS[$class]->title,
                        'payment_module_code' => $GLOBALS[$class]->code,
...

So if I interpret this correctly, $class is the current payment method, 'cod', and $GLOBALS['cod'] should be set, but isn't.
I'm not positive that this is THE error that is ultimately causing the Ajax error I am seeing, but I don't see a similar error showing up when I use authorizenet_aim. ...
Do you have the full "stack trace" for the posted warning messages, or just what was posted?

Have any modifications been made to programmatically "disable" or "hide" any payment methods?

Are sessions working correctly on the site ("zenid=" query string goes away while browsing the site)?

Have you tried clearing all cookies related the site (will result in a new "clean" session as long as the "zenid=" query string is not in the URL)?

Do you have any AntiVirus, AntiSpyware, AdBlocker, or other locally installed filter / proxy?

Does this only occur when using Internet Explorer (If yes, what version are you using)?

Can you post the contents of any ".htaccess" files (including those in parent folders)?

Do you have any "backup" copies of payment modules in "/includes/modules/payment/"?

Is the COD payment module filename still named "cod.php"? Have any modifications been made to this file?

Is the COD payment module enabled when you visit "admin" -> "modules" -> "payment"?

Are there any errors or messages shown when you visit "admin" -> "modules" -> "payment"?

Is the entire page shown (including the footer) when you visit "admin" -> "modules" -> "payment"?

Can you search and see if any modifications to the store touch $cod, $_GLOBALS["cod"], or $_CLOBALS['cod'].

Are there any other Zen Cart debug logs?

There are lots of questions here. I will do my best to answer them all correctly.

lhungil:

Do you have the full "stack trace" for the posted warning messages, or just what was posted?
After turning on lat9's Report All Errors, and adding some error_log calls, I have 5 debug files, some of which contain the messages generated by my calls to error_log, and some generated by the Report All Errors. Each file is on the order of 114000 bytes. Do you want me to include the contents of all 5 of those files?
lhungil:

Have any modifications been made to programmatically "disable" or "hide" any payment methods?
In the cod module, I have some code which only allows this module for customers_group_pricing 2. But I tried removing that code, and reinstalling the module, and I still got the same behavior. And I don't have any modifications to the paypal module, and I get the ajax error with that module too.
lhungil:

Are sessions working correctly on the site ("zenid=" query string goes away while browsing the site)?
yes, sessions appear to be working correctly. I do not see "zenid=".
lhungil:

Have you tried clearing all cookies related the site (will result in a new "clean" session as long as the "zenid=" query string is not in the URL)?
No, I haven't tried this. I need to figure out how to do this in firefox
lhungil:

Do you have any AntiVirus, AntiSpyware, AdBlocker, or other locally installed filter / proxy?
I have Norton 360 installed on my PC. Is that what you are asking?
lhungil:

Does this only occur when using Internet Explorer (If yes, what version are you using)?
This occurs using Firefox, Internet Explorer, and Chrome.
lhungil:

Can you post the contents of any ".htaccess" files (including those in parent folders)?
There is only 1 .htaccess for the test version of the store. There is no parent directory .htaccess file.

##### NOTE: Replace /shop/ with the relative web path of your catalog in the "Rewrite Base" line below:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

# From Ultimate SEO URLs
RewriteRule ^(.*)-p-(.*).html$ index\.php?main_page=product_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-(.*).html$ index\.php?main_page=index&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-m-([0-9]+).html$ index\.php?main_page=index&manufacturers_id=$2&%{QUERY_STRING} [L]
#RewriteRule ^(.*)-m-([0-9]+)(.*)$ index\.php?main_page=index&manufacturers_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pi-([0-9]+).html$ index\.php?main_page=popup_image&pID=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pr-([0-9]+).html$ index\.php?main_page=product_reviews&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pri-([0-9]+).html$ index\.php?main_page=product_reviews_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-ezp-([0-9]+).html$ index\.php?main_page=page&id=$2&%{QUERY_STRING} [L]
# All other pages
# Don't rewrite real files or directories
RewriteCond %{REQUEST_FILENAME} !-f [NC]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*).html$ index\.php?main_page=$1&%{QUERY_STRING} [L]

<Files 403.shtml>
order allow,deny
allow from all
</Files>

deny from xx.xxx.x.x/xx
... a bunch more deny lines

lhungil:

Do you have any "backup" copies of payment modules in "/includes/modules/payment/"?
I do have a backup version of cod.php, cod.php.bak, which is the version that doesn't contain my modification for only allowing the mod for customers_group_pricing 2. But I don't see this version showing up in the admin payment modules.
lhungil:

Is the COD payment module filename still named "cod.php"? Have any modifications been made to this file?
The filename is still named cod.php. The modifications are as follows:
within function cod() {...}, see the bof: LEFP ... eof: LEFP

    function cod() {
      global $order;

      $this->code = 'cod';
      $this->title = MODULE_PAYMENT_COD_TEXT_TITLE;
      $this->description = MODULE_PAYMENT_COD_TEXT_DESCRIPTION;
      $this->sort_order = MODULE_PAYMENT_COD_SORT_ORDER;
      $this->enabled = ((MODULE_PAYMENT_COD_STATUS == 'True') ? true : false);

      if ((int)MODULE_PAYMENT_COD_ORDER_STATUS_ID > 0) {
        $this->order_status = MODULE_PAYMENT_COD_ORDER_STATUS_ID;
      }

      // bof: LEFP: Only allow for customers_group_pricing 2 (admin).
      // Used for testing, or for placing sample orders
      if (!IS_ADMIN_FLAG) {
        global $db;
        $group_query = $db->Execute("select customers_group_pricing from " . TABLE_CUSTOMERS . " where customers_id = '" . (int)$_SESSION['customer_id'] . "'");
        if ($group_query->fields['customers_group_pricing'] != '2') {
          $this->enabled = false;
        }
      }
      // eof: LEFP: Only allow for customers_group_pricing 2
      if (is_object($order)) $this->update_status();
    }

lhungil:

Is the COD payment module enabled when you visit "admin" -> "modules" -> "payment"?
yes
lhungil:

Are there any errors or messages shown when you visit "admin" -> "modules" -> "payment"?
no
lhungil:

Is the entire page shown (including the footer) when you visit "admin" -> "modules" -> "payment"?
yes
lhungil:

Can you search and see if any modifications to the store touch $cod, $_GLOBALS["cod"], or $_CLOBALS['cod'].
I did not see any references to $_GLOBALS["cod"] or $_GLOBALS['cod'], and I only found $cod in includes/modules/order_total/ot_cod_fee.php and includes/modules/payment/cod.php
lhungil:

Are there any other Zen Cart debug logs?
Before I turned on Report All Errors, and started adding calls to error_log, no debug logs showed up in my logs directory.

Can you verify Authorization Pending is not set to 1 (or the patch is applied)? Probably not the issue, but if enabled (and the patch is not applied) it can cause a redirect on the ajax request.

earth-friendly:

... In the cod module, I have some code which only allows this module for customers_group_pricing ...
Your posted code should be fine as long as the customer is still logged in.

earth-friendly:

... There is only 1 .htaccess for the test version of the store. There is no parent directory .htaccess file. ...
Looks like an older version of Ultimate SEO URLs. If you have "automatic redirects" enabled, this could be potentially be part of the problem (the ajax code calls application_top - so will be evaluated for a redirect). Handling for ajax.php (and other scripts calling application_top directly) was added in the latest release of Ultimate URLs. If for some reason you MUST stay on the older version, disable automatic redirects (but it would be better to upgrade).

earth-friendly:

... I do have a backup version of cod.php, cod.php.bak ...
Please remove any backups from the "/includes/modules/*/" folders. Leaving them has been known to cause issues in the past.

earth-friendly:

... No, I haven't tried this. I need to figure out how to do this in firefox ...
"Options" -> "Privacy" -> "Show Cookies". Or via FireBug on the "cookies" menu you can remove them.

earth-friendly:

... I did not see any references to $_GLOBALS["cod"] or $GLOBALS['cod'], and I only found $cod in includes/modules/order_total/ot_cod_fee.php and includes/modules/payment/cod.php ...
Not seeing "$cod" in those files (from the Zen Cart 1.5.4 distribution archive), just "$cod*"... Is this what you are seeing in your installed files?

lhungil:

Can you verify Authorization Pending is not set to 1 (or the patch is applied)? Probably not the issue, but if enabled (and the patch is not applied) it can cause a redirect on the ajax request.
Authorization Pending is not set to 1

lhungil:

Looks like an older version of Ultimate SEO URLs. If you have "automatic redirects" enabled, this could be potentially be part of the problem (the ajax code calls application_top - so will be evaluated for a redirect). Handling for ajax.php (and other scripts calling application_top directly) was added in the latest release of Ultimate URLs. If for some reason you MUST stay on the older version, disable automatic redirects (but it would be better to upgrade).
Oops, I have 1.50 installed for Ultimate SEO Urls. I thought I had upgraded to the latest version, but I guess not. When I first saw your comment about this, I looked at the .htaccess files, and thought I had just forgotten to install the new .htaccess file for 2.15, so I did that, but it didn't solve the problem, and my shopping cart link now goes to a 404 error. I need to upgrade completely, and I'll work on that.
However, I did check, and I do have automatic redirects disabled in Ultimate SEO Urls, so it sounds like from what you said, my older version of this mod would not be causing the problem?
lhungil:

Please remove any backups from the "/includes/modules/*/" folders. Leaving them has been known to cause issues in the past.
I removed the backups, and I still have the problem.
lhungil:

"Options" -> "Privacy" -> "Show Cookies". Or via FireBug on the "cookies" menu you can remove them.
I removed the cookies relating to my site, and I still have the problem.
lhungil:

Not seeing "$cod" in those files (from the Zen Cart 1.5.4 distribution archive), just "$cod_"... Is this what you are seeing in your installed files?
Yes, you are correct. Just "$cod_", no "$cod". Sorry for the confusion. My eyes just got tired looking at all the results :)

So, it looks like I do need to upgrade Ultimate SEO Urls, but it also looks like that is not the cause of the ajax problem I am seeing :(
lhungil, thanks so much for all your help so far! I really appreciate it! And thanks again to lat9 and carlwhat.
Hopefully we can get to the root of this problem!
Any other suggestions at this point? I'm thinking of figuring out more places to put in error_log calls.
And I'm wondering if those lines that I reported above, in the debug file were significant:

Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 352
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 352
Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 353
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 353

I can't believe this, after so many days of working on this--I think I have finally fixed the problem!
Something that lhungil said made me wonder if all my templates had been upgraded appropriately to handle the ajax changes.
I used my favorite comparison program, Beyond Compare, and I compared the includes/templates folders for 1.5.3 and 1.5.4 to see what had changed. I then went through the changes to make sure I had made these changes to my templates.
The problem was in the tpl_checkout_payment_default.php template.
I had upgraded to the latest version of COWOA, the beta version, 2.6, but I don't think this version has been upgraded to 1.5.4.
The line that I think was causing the problem is:
1.5.3:

<?php echo zen_draw_form('checkout_payment', zen_href_link(FILENAME_CHECKOUT_CONFIRMATION, '', 'SSL'), 'post', ($flagOnSubmit ? 'onsubmit="return check_form();"' : '')); ?>

1.5.4:

<?php echo zen_draw_form('checkout_payment', zen_href_link(FILENAME_CHECKOUT_CONFIRMATION, '', 'SSL'), 'post'); ?>

and the other difference, at the end of this file:
1.5.3:

<div class="buttonRow forward"><?php echo zen_image_submit(BUTTON_IMAGE_CONTINUE_CHECKOUT, BUTTON_CONTINUE_ALT, 'onclick="submitFunction('.zen_user_has_gv_account($_SESSION['customer_id']).','.$order->info['total'].')"'); ?></div>

1.5.4:

<div class="buttonRow forward" id="paymentSubmit"><?php echo zen_image_submit(BUTTON_IMAGE_CONTINUE_CHECKOUT, BUTTON_CONTINUE_ALT, 'onclick="submitFunction('.zen_user_has_gv_account($_SESSION['customer_id']).','.$order->info['total'].')"'); ?></div>

I don't understand the details of how the differences affected the flow, but I now no longer get the ajax error!!!
Thank you so much to lhungil, lat9, and carlwhat for all your help and suggestions! I really appreciate it. And I learned a lot about debugging php and zencart.
I think I need to go to the COWOA forum post, to let them know about this issue, so they can make sure to add in this change.
And, I should probably upgrade to the latest version of Ultimate SEO Urls when I have some time. I need to understand the details of how it has changed. But for now, I am very happy, because I got rid of that error, and I'm almost at the point where I can upgrade my live site!!!:smile::clap::jump::thumbsup:

earth-friendly:

I can't believe this, after so many days of working on this--I think I have finally fixed the problem! ...
Awesome! Thank you for sticking with it and posting the solution.

Have the warnings been resolved, or are they still occuring (was hoping to track those down by eliminating some of the possible causes).

lhungil:

Have the warnings been resolved, or are they still occuring (was hoping to track those down by eliminating some of the possible causes).
The Ajax error that appeared briefly, and then disappeared, has stopped occurring. Are you referring to the 4 lines that I displayed, when I turned on Report All Errors? I haven't checked for that yet. I'll look later today. That prints out zillions of lines of warnings. I saw other warnings in there too, which looked problematic, but they didn't appear to be related to this issue.

lhungil:

Awesome! Thank you for sticking with it and posting the solution.
My pleasure! Thanks for helping to support me through the process!
lhungil:

Have the warnings been resolved, or are they still occuring (was hoping to track those down by eliminating some of the possible causes).
After fixing the 2 lines of code in my template file, tpl_checkout_payment_default.php, I just went through the checkout process again, turning on "Report All Errors" while on the "checkout payment" page, before continuing on to the "checkout confirmation" page. I do still see these warnings:

Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 352
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 352
Undefined index: cod in /home/myuser/MyTest/includes/classes/order.php on line 353
Trying to get property of non-object in /home/myuser/MyTest/includes/classes/order.php on line 353

I don't know if they are anything to worry about.

earth-friendly:

I can't believe this, after so many days of working on this--I think I have finally fixed the problem!
Something that lhungil said made me wonder if all my templates had been upgraded appropriately to handle the ajax changes.
I used my favorite comparison program, Beyond Compare, and I compared the includes/templates folders for 1.5.3 and 1.5.4 to see what had changed. I then went through the changes to make sure I had made these changes to my templates.
The problem was in the tpl_checkout_payment_default.php template.
I had upgraded to the latest version of COWOA, the beta version, 2.6, but I don't think this version has been upgraded to 1.5.4.COWOA v2.6 was updated to 1.5.4, but these template files were inadvertently left out.. Those changes have been fixed in the Github repo... Thanks for bringing this to the communities attention..