- Welcome to AbanteCart Community.
AbanteCart forum
Recent posts
#1
Extension Support / Re: Possible bug in USPS exten...
Last post by Heemet - Today at 06:05:53 PMHello Basura,
Thank you for your reply. Regarding USPS media mail, are we able to configure a product in AbanteCart to flag it as eligible for USPS media mail, so that a user can select it as a shipping option? I don't see a setting on the configuration page for a product to identify it as eligible for media mail.
Thank you!
Thank you for your reply. Regarding USPS media mail, are we able to configure a product in AbanteCart to flag it as eligible for USPS media mail, so that a user can select it as a shipping option? I don't see a setting on the configuration page for a product to identify it as eligible for media mail.
Thank you!
#2
Extension Support / [Possible Bug + Fixes] PayPal ...
Last post by RCodiaDavid - Today at 01:16:38 PMAbanteCart version: 1.4.4
Extension: Paypal Commerce
Payment action: Capture (Sale)
File affected: extensions/paypal_commerce/storefront/controller/responses/extension/paypal_commerce.php
Background
After updating to 1.4.4, PayPal payments were being taken but orders were not appearing in the admin, and customers were being left on the checkout confirmation page with their cart still full. I want to stress that this may be specific to my own setup or update path. I'm not certain these are universal bugs, but I couldn't find any existing posts about it and wanted to share what I found in case it helps anyone else in the same situation.
Symptoms
Customer pays via PayPal successfully & money is taken
Order does not appear in AbanteCart admin (or appears under "Incomplete" status, which is filtered out of the default admin order view)
After payment, customer is left on the checkout confirmation page with their cart still full, no redirect to the order confirmation page
PayPal error log shows: Paypal webhook PAYMENT.CAPTURE.COMPLETED: order ID XXXXX / Paypal related OrderId: XXXXXXXXXXXXXXXXX but not found in the database
What I think was happening
After digging through the code I found three separate issues that combined to break the checkout flow. These may have been introduced during my update to 1.4.4 or may be specific to my configuration, I can't say for certain. I'm sharing them here in case anyone else hits the same problems.
Issue 1: array_merge null crash in captureOrder()
$this->session->data['fc'] appeared to be null in my checkout path, causing a fatal error that crashed the entire captureOrder() method:
array_merge(): Argument #2 must be of type array, null given
Issue 2: Possible race condition: orders stuck as "incomplete"
Even without Issue 1, captureOrder() doesn't confirm the AbanteCart order itself, it relies on the browser making a subsequent call to send() → processGenericOrder() to do that. In my case, PayPal's PAYMENT.CAPTURE.COMPLETED webhook was arriving before the browser's send() call ran. The webhook handler calls update() on the order, which appears to do nothing on an unconfirmed/incomplete order. The result was orders remaining in "Incomplete" status, hidden from the default admin filter. This timing may vary between setups.
Issue 3: Duplicate INSERT crashing processGenericOrder(), cart never clearing
Once I fixed Issue 2 by saving the PayPal order record in captureOrder(), the subsequent send() call reached processGenericOrder(), which unconditionally calls savePaypalOrder() again for the same order. Since savePaypalOrder() uses a plain INSERT with no duplicate handling, this threw a database error that silently killed the method, so the checkout/finalize redirect URL was never returned to the browser and the cart was never cleared.
What I did to fix it
Fix 1: array_merge null crash
In captureOrder(), find:
Replace with:
Fix 2: Confirm order and save PayPal record immediately in captureOrder()
In captureOrder(), find the closing of the if ($orderInfo) block followed by the catch:
Replace with:
Fix 3: Guard duplicate savePaypalOrder in processGenericOrder()
In processGenericOrder(), find:
Replace with:
Fix 4: Improve webhook fallback in processWebHook()
In processWebHook(), find:
Bonus: Order numbers missing from PayPal transaction exports
I also noticed that the "Custom Number" column in PayPal's transaction export spreadsheet was blank for all orders placed after updating to 1.4.4 (or maybe earlier). In older versions this column showed the AbanteCart order number, which is useful for reconciliation. The custom_id field appears to have been removed from the PayPal purchase unit payload in 1.4.4, possibly intentionally since the webhook lookup mechanism changed to use reference_id instead. Adding it back as a plain order number restores the column in exports without affecting anything else.
In prepareOrderData(), find:
Note for existing incomplete orders
If you have orders already stuck in "Incomplete" status where payment was successfully taken, go to Sales → Orders, filter by "Incomplete" status, open each affected order, change the status to Processing (or your configured success status), and tick "Notify Customer" to send the confirmation email. I think this works, not fully tested yet.
I'm not a core developer so there may be good reasons some of this works differently by design, happy to be corrected. (Please don't flame me if I've gone overboard)
Posting in case it's useful to anyone else who updated to 1.4.4 and is seeing the same symptoms.
Extension: Paypal Commerce
Payment action: Capture (Sale)
File affected: extensions/paypal_commerce/storefront/controller/responses/extension/paypal_commerce.php
Background
After updating to 1.4.4, PayPal payments were being taken but orders were not appearing in the admin, and customers were being left on the checkout confirmation page with their cart still full. I want to stress that this may be specific to my own setup or update path. I'm not certain these are universal bugs, but I couldn't find any existing posts about it and wanted to share what I found in case it helps anyone else in the same situation.
Symptoms
Customer pays via PayPal successfully & money is taken
Order does not appear in AbanteCart admin (or appears under "Incomplete" status, which is filtered out of the default admin order view)
After payment, customer is left on the checkout confirmation page with their cart still full, no redirect to the order confirmation page
PayPal error log shows: Paypal webhook PAYMENT.CAPTURE.COMPLETED: order ID XXXXX / Paypal related OrderId: XXXXXXXXXXXXXXXXX but not found in the database
What I think was happening
After digging through the code I found three separate issues that combined to break the checkout flow. These may have been introduced during my update to 1.4.4 or may be specific to my configuration, I can't say for certain. I'm sharing them here in case anyone else hits the same problems.
Issue 1: array_merge null crash in captureOrder()
$this->session->data['fc'] appeared to be null in my checkout path, causing a fatal error that crashed the entire captureOrder() method:
array_merge(): Argument #2 must be of type array, null given
Issue 2: Possible race condition: orders stuck as "incomplete"
Even without Issue 1, captureOrder() doesn't confirm the AbanteCart order itself, it relies on the browser making a subsequent call to send() → processGenericOrder() to do that. In my case, PayPal's PAYMENT.CAPTURE.COMPLETED webhook was arriving before the browser's send() call ran. The webhook handler calls update() on the order, which appears to do nothing on an unconfirmed/incomplete order. The result was orders remaining in "Incomplete" status, hidden from the default admin filter. This timing may vary between setups.
Issue 3: Duplicate INSERT crashing processGenericOrder(), cart never clearing
Once I fixed Issue 2 by saving the PayPal order record in captureOrder(), the subsequent send() call reached processGenericOrder(), which unconditionally calls savePaypalOrder() again for the same order. Since savePaypalOrder() uses a plain INSERT with no duplicate handling, this threw a database error that silently killed the method, so the checkout/finalize redirect URL was never returned to the browser and the cart was never cleared.
What I did to fix it
Fix 1: array_merge null crash
In captureOrder(), find:
Code Select
$this->session->data['fc'] = array_merge($order->data, $this->session->data['fc']);Replace with:
Code Select
$this->session->data['fc'] = array_merge((array)$order->data, (array)$this->session->data['fc']);Fix 2: Confirm order and save PayPal record immediately in captureOrder()
In captureOrder(), find the closing of the if ($orderInfo) block followed by the catch:
Code Select
$order->buildOrderData($this->session->data['fc']);
$order->saveOrder();
}
} catch (Exception|Error $e) {Replace with:
Code Select
$order->buildOrderData($this->session->data['fc']);
$order->saveOrder();
}
$confirmOrderId = (int)($orderId ?: $this->session->data['order_id']);
if ($confirmOrderId && $result->getId()) {
/** @var ModelCheckoutOrder $oMdl */
$oMdl = $this->loadModel('checkout/order');
$confirmedOrderInfo = $oMdl->getOrder($confirmOrderId);
$incompleteStatusId = (int)$this->order_status->getStatusByTextId('incomplete');
$currentStatusId = (int)($confirmedOrderInfo['order_status_id'] ?? 0);
if ($confirmedOrderInfo && (!$currentStatusId || $currentStatusId == $incompleteStatusId)) {
$settledStatusId = $this->config->get('paypal_commerce_transaction_type') == 'capture'
? $this->config->get('paypal_commerce_status_success_settled')
: $this->config->get('paypal_commerce_status_success_unsettled');
$oMdl->confirm(
$confirmOrderId,
$settledStatusId ?: $this->order_status->getStatusByTextId('pending')
);
}
if (!$mdl->getPaypalOrder($confirmOrderId)) {
$mdl->savePaypalOrder($confirmOrderId, [
'id' => $ppOrderId,
'transaction_id' => $result->getId(),
]);
}
}
} catch (Exception|Error $e) {Fix 3: Guard duplicate savePaypalOrder in processGenericOrder()
In processGenericOrder(), find:
Code Select
$mdl->savePaypalCustomer($this->customer->getId(), $transactionDetails['payer']['payer_id']);
$mdl->savePaypalOrder(
$orderId,
[
'id' => $transactionDetails['id'],
'transaction_id' => $transactionDetails['id'],
]
);Replace with:
Code Select
$mdl->savePaypalCustomer($this->customer->getId(), $transactionDetails['payer']['payer_id']);
if (!$mdl->getPaypalOrder($orderId)) {
$mdl->savePaypalOrder(
$orderId,
[
'id' => $transactionDetails['id'],
'transaction_id' => $transactionDetails['id'],
]
);
}Fix 4: Improve webhook fallback in processWebHook()
In processWebHook(), find:
Code Select
/** @var ModelCheckoutOrder $oMdl */
$oMdl = $this->loadModel('checkout/order');
$oMdl->update(
$orderId,
$this->data['order_status_id'],
'Order updated by Paypal webhook request.'
);Replace with:Code Select
/** @var ModelCheckoutOrder $oMdl */
$oMdl = $this->loadModel('checkout/order');
/** @var ModelExtensionPaypalCommerce $mdl */
$mdl = $this->loadModel('extension/paypal_commerce');
$webhookOrderInfo = $oMdl->getOrder($orderId);
$incompleteStatusId = (int)$this->order_status->getStatusByTextId('incomplete');
$currentStatusId = (int)($webhookOrderInfo['order_status_id'] ?? 0);
if ($webhookOrderInfo && (!$currentStatusId || $currentStatusId == $incompleteStatusId)) {
$oMdl->confirm($orderId, $this->data['order_status_id']);
if (!$mdl->getPaypalOrder($orderId)) {
$ppOrderId = $inData['parsed']['resource']['supplementary_data']['related_ids']['order_id'] ?? '';
$mdl->savePaypalOrder($orderId, [
'id' => $ppOrderId,
'transaction_id' => $inData['parsed']['resource']['id'] ?? '',
]);
}
} else {
$oMdl->update(
$orderId,
$this->data['order_status_id'],
'Order updated by Paypal webhook request.'
);
}Bonus: Order numbers missing from PayPal transaction exports
I also noticed that the "Custom Number" column in PayPal's transaction export spreadsheet was blank for all orders placed after updating to 1.4.4 (or maybe earlier). In older versions this column showed the AbanteCart order number, which is useful for reconciliation. The custom_id field appears to have been removed from the PayPal purchase unit payload in 1.4.4, possibly intentionally since the webhook lookup mechanism changed to use reference_id instead. Adding it back as a plain order number restores the column in exports without affecting anything else.
In prepareOrderData(), find:
Code Select
$this->data['pp']['purchase_units'][0] = [
'reference_id' => $ppOrderData['data']['reference_id'] ? : $this->session->data['reference_id'],
'amount' => [Replace with:Code Select
$this->data['pp']['purchase_units'][0] = [
'reference_id' => $ppOrderData['data']['reference_id'] ? : $this->session->data['reference_id'],
'custom_id' => (string) $orderId,
'amount' => [Note for existing incomplete orders
If you have orders already stuck in "Incomplete" status where payment was successfully taken, go to Sales → Orders, filter by "Incomplete" status, open each affected order, change the status to Processing (or your configured success status), and tick "Notify Customer" to send the confirmation email. I think this works, not fully tested yet.
I'm not a core developer so there may be good reasons some of this works differently by design, happy to be corrected. (Please don't flame me if I've gone overboard)
Posting in case it's useful to anyone else who updated to 1.4.4 and is seeing the same symptoms.
#3
Extension Support / Re: Possible bug in USPS exten...
Last post by Basara - Today at 02:53:33 AMHello,
Thanks for reporting this and for testing the new USPS extension in 1.4.4.
Regarding your first point: Bound Printed Matter, Media Mail, and Library Mail are special USPS package services with additional eligibility requirements. They are included in the extension for merchants who specifically need to ship those types of products, but they will not appear as options for regular products in the cart.
As for the duplicate USPS Ground Advantage option - we are aware of this behavior during development. It seems to be related to how the USPS API currently returns Parcel Select services. In some cases, USPS is returning Ground Advantage under both Parcel Select and Ground Advantage, which results in a duplicate entry. Unfortunately, this is not something we can control on the AbanteCart side. The workaround is to disable the Parcel Select method in your extension configuration, which should prevent the duplication.
We always advise contacting USPS support directly to consult about available services. Please let us know if they provide more details or if they add new services for regular products, so we can keep the extension aligned with their offerings.
Thanks again for your feedback and for helping improve the extension.
Thanks for reporting this and for testing the new USPS extension in 1.4.4.
Regarding your first point: Bound Printed Matter, Media Mail, and Library Mail are special USPS package services with additional eligibility requirements. They are included in the extension for merchants who specifically need to ship those types of products, but they will not appear as options for regular products in the cart.
As for the duplicate USPS Ground Advantage option - we are aware of this behavior during development. It seems to be related to how the USPS API currently returns Parcel Select services. In some cases, USPS is returning Ground Advantage under both Parcel Select and Ground Advantage, which results in a duplicate entry. Unfortunately, this is not something we can control on the AbanteCart side. The workaround is to disable the Parcel Select method in your extension configuration, which should prevent the duplication.
We always advise contacting USPS support directly to consult about available services. Please let us know if they provide more details or if they add new services for regular products, so we can keep the extension aligned with their offerings.
Thanks again for your feedback and for helping improve the extension.
#4
Extension Support / Possible bug in USPS extension...
Last post by Heemet - May 18, 2026, 11:12:09 PMHello,
I recently upgraded to version 1.4.4. Thanks to everyone who worked hard on this new version.
I installed the new USPS extension, and I have noticed there are two bugs:
1.) The only shipping options that appear are Priority Mail, Priority Mail Express, and USPS Ground Advantage. See screenshot in attachment 1.
These are the only three options despite all shipping options being selected in my configuration, except for USPS Ground Advantage (more on that below). See screenshot in attachment 2.
2). Note that USPS Ground Advantage is turned off in my instance of the extension. If I turn it on, USPS Ground Advantage appears twice in the shipping estimate as a shipping option. See screenshot in attachment 3.
I tried a fresh installation of v. 1.4.4, and I noticed the same bug. My error log is clear.
Thanks!
I recently upgraded to version 1.4.4. Thanks to everyone who worked hard on this new version.
I installed the new USPS extension, and I have noticed there are two bugs:
1.) The only shipping options that appear are Priority Mail, Priority Mail Express, and USPS Ground Advantage. See screenshot in attachment 1.
These are the only three options despite all shipping options being selected in my configuration, except for USPS Ground Advantage (more on that below). See screenshot in attachment 2.
2). Note that USPS Ground Advantage is turned off in my instance of the extension. If I turn it on, USPS Ground Advantage appears twice in the shipping estimate as a shipping option. See screenshot in attachment 3.
I tried a fresh installation of v. 1.4.4, and I noticed the same bug. My error log is clear.
Thanks!
#5
Template Support / Re: upgrade from 1.4.3 to 1.4....
Last post by Basara - May 15, 2026, 02:48:41 AMHello
This is not related to the NOVATOR template. Europe/Istanbul is a valid PHP timezone, but MySQL/MariaDB is rejecting it because probably your hosting does not allow to set it.
In most cases this warning can be ignored, as it rarely causes serious issues. However, the proper fix is on the database server side. Ask your hosting provider/server admin to set MySQL timezone to match your php timezone.
This is not related to the NOVATOR template. Europe/Istanbul is a valid PHP timezone, but MySQL/MariaDB is rejecting it because probably your hosting does not allow to set it.
In most cases this warning can be ignored, as it rarely causes serious issues. However, the proper fix is on the database server side. Ask your hosting provider/server admin to set MySQL timezone to match your php timezone.
#6
Template Support / upgrade from 1.4.3 to 1.4.4 in...
Last post by G. O. - May 14, 2026, 01:39:47 PMHello,
i upgraded from 1.4.3 to 1.4.4 and getting incorrect time zone error as follow:
2026-05-14 19:09:57 - 1298: Unknown or incorrect time zone: 'Europe/Istanbul'
SET time_zone='Europe/Istanbul';
I use default template of NOVATOR
php: 8.4.20
what is the fix for this issue?
Thanks in advanced
i upgraded from 1.4.3 to 1.4.4 and getting incorrect time zone error as follow:
2026-05-14 19:09:57 - 1298: Unknown or incorrect time zone: 'Europe/Istanbul'
SET time_zone='Europe/Istanbul';
I use default template of NOVATOR
php: 8.4.20
what is the fix for this issue?
Thanks in advanced
#7
General Support / Re: Delete spam customers
Last post by G. O. - May 14, 2026, 10:51:40 AMQuote from: timlight10 on May 09, 2026, 02:09:04 PMI have reCaptcha enabled, but I still get spam customers and contact form entries. Any suggestions?this is mostly your business filed competitors doing it to you.
#8
General Support / Re: Delete spam customers
Last post by timlight10 - May 11, 2026, 09:31:25 AMThank you, I have updated these as suggested and let you know if the situation improves.
#9
General Support / Re: Delete spam customers
Last post by Basara - May 11, 2026, 02:27:09 AMQuote from: timlight10 on May 09, 2026, 02:09:04 PMI have reCaptcha enabled, but I still get spam customers and contact form entries. Any suggestions?Hello.
Make sure reCAPTCHA is enabled for all relevant pages/forms and switch to reCAPTCHA v3, and consider increasing the score threshold in reCAPTCHA settings
#10
General Support / Re: AbanteCart core v.1.4.4 In...
Last post by Basara - May 11, 2026, 02:23:15 AMHello.
We tested an upgrade from 1.4.3 to 1.4.4, and UPS is working correctly in that case.
This error points to a missing dependency/class file from the UPS SDK rather than a general checkout issue.
Please compare your installed UPS extension files with the current 1.4.4 master UPS files here:
https://github.com/abantecart/abantecart-src/tree/master/public_html/extensions/ups
Pay special attention to the extensions/ups/core/ups_sdk/vendor/ directory and make sure all files are present and uploaded correctly. Also check file and folder permissions so PHP can read these files.
Another possibility is hosting-side security filtering. If your host has an internal firewall, for example ModSecurity, it may block part of the new UPS code or its requests. You may need to ask the hosting provider to check the ModSecurity/firewall logs for blocked requests related to the UPS extension.
We tested an upgrade from 1.4.3 to 1.4.4, and UPS is working correctly in that case.
This error points to a missing dependency/class file from the UPS SDK rather than a general checkout issue.
Please compare your installed UPS extension files with the current 1.4.4 master UPS files here:
https://github.com/abantecart/abantecart-src/tree/master/public_html/extensions/ups
Pay special attention to the extensions/ups/core/ups_sdk/vendor/ directory and make sure all files are present and uploaded correctly. Also check file and folder permissions so PHP can read these files.
Another possibility is hosting-side security filtering. If your host has an internal firewall, for example ModSecurity, it may block part of the new UPS code or its requests. You may need to ask the hosting provider to check the ModSecurity/firewall logs for blocked requests related to the UPS extension.