Recent posts

#31

Extension Support / Re: [Possible Bug + Fixes] Pay...

Last post by RCodiaDavid - May 24, 2026, 04:33:32 AM

Hi Basara, thanks for following up.

To answer your questions:
Customer Country: UK
Order Currency: GBP
Paypal Method: PayPal Commerce (standard button on the fast checkout page)
Checkout buttons enabled: No
Product type: Physical goods only

Regarding the specific incident, I have been waiting for payment confirmation from the customer as I don't have access to their PayPal directly. It has come to light that PayPal automatically detected and refunded the duplicate charges, so the customer was not out of pocket.

But to clarify the symptoms further, in some cases the order was created in Abantecart, and payment was taken, but the customer was not redirected to a confirmation page and their cart remained full. This suggests a browser side callback was not completing reliably, leaving the customer with no confirmation even though the order had gone through on the backend.

That said, looking into the issue made it clear that there are some edge cases in the checkout flow worth addressing. The fixes I have applied locally add a reliable fallback for situations where the browser side callback does not complete, for example: if a customer loses their connection or closes the tab after PayPal has taken payment. This ensures the order is still confirmed in Abantecart even if the browser callback fails.

I hope this helps is some way.

#32

Template Support / Re: database issue

Last post by G. O. - May 21, 2026, 04:53:48 PM

Hello.
Products may also be missing from Admin if cache is outdated, or if the product is not assigned to the store view you are checking.

Those names are stored in the product description table. To check them in the database, use your own AbanteCart table prefix from system/config.php (DB_PREFIX) and run

Code Select Expand

SELECT name
FROM prefix_product_descriptions
WHERE name LIKE '%( Copy )%';
but it is unsafe to delete only from product_descriptions, because products are linked across several tables.

thank you for support, actually they were very old products data and we already deleted them from website dashboard but on database still saved and i don't know why they stayed there if already deleted them from the panel. any way I did solved my issue but there is still a small issue. when the AI BOT retrieving the data about products from the database table we have n the product description section an html info and the AI BOT printing them in the answer section and still trying to find a solution for this too.

#33

Template Support / Re: database issue

Last post by Basara - May 21, 2026, 05:56:28 AM

Hello.
Products may also be missing from Admin if cache is outdated, or if the product is not assigned to the store view you are checking.

Those names are stored in the product description table. To check them in the database, use your own AbanteCart table prefix from system/config.php (DB_PREFIX) and run

Code Select Expand

SELECT name
FROM prefix_product_descriptions
WHERE name LIKE '%( Copy )%';
but it is unsafe to delete only from product_descriptions, because products are linked across several tables.

#34

Template Support / Re: database issue

Last post by G. O. - May 21, 2026, 12:56:24 AM

Hello.
In AbanteCart admin, search for "( Copy )", select all, and remove. Direct database edits are strongly discouraged.

the problem is not on admin side, there is nothing in products side panel, it is in the database. I'm getting this information when we are exporting products information from database information to website AI Assistant bot, bot retrieving these information from product id table

#35

Template Support / Re: database issue

Last post by Basara - May 20, 2026, 10:25:54 AM

Hello.
In AbanteCart admin, search for "( Copy )", select all, and remove. Direct database edits are strongly discouraged.

#36

Template Support / database issue

Last post by G. O. - May 20, 2026, 08:06:03 AM

Hello,

i need you help to know the best way to remove these duplication on database as you see in the bottom extracted text: how to remove these duplications from database? all of this came from cloning the products for fast edits of products details 📊 Found 356 duplicate/copy products

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DUPLICATE PRODUCTS LIST:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 ORIGINAL/CATEGORY: 01-171 ( Copy )
  └─ Duplicate: 01-171 ( Copy ) (ID: 2103)
  └─ Duplicate: 01-171 ( Copy ) (ID: 2103)
  └─ Duplicate: 01-171 ( Copy ) (ID: 2143)
  └─ Duplicate: 01-171 ( Copy ) (ID: 2143)
  Total copies: 4


📦 ORIGINAL/CATEGORY: 01-171 ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy )
  └─ Duplicate: 01-171 ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) (ID: 2110)
  └─ Duplicate: 01-171 ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) (ID: 2110)
  └─ Duplicate: 01-171 ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) (ID: 2149)
  └─ Duplicate: 01-171 ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) ( Copy ) (ID: 2149)
  Total copies: 4



they are 📊 Found 356 duplicate/copy products and this is just a sample of what i have in the database

#37

Tips and Tricks / Re: AI and AbanteCart

Last post by Wang Evelyn - May 20, 2026, 06:09:52 AM

I've been experimenting with AI tools for smaller AbanteCart customizations and they're surprisingly useful for speeding up template edits, SQL queries, and extension debugging. The biggest benefit for me is explaining unfamiliar parts of the codebase quickly instead of digging through files manually.

Still important to review everything carefully though, especially for payment logic or checkout modifications. AI saves time, but it can definitely generate code that looks correct while breaking existing functionality.

#38

Extension Support / Re: [Possible Bug + Fixes] Pay...

Last post by Basara - May 20, 2026, 02:46:19 AM

Hi RCodiaDavid,

Thanks for taking the time to write this up and share the fixes you tried.

Before we can say much about the cause, we need a few more details about the actual PayPal transactions. PayPal Commerce can route payments through different methods depending on the customer and country, so this may not be the same path for every order.

Can you please check one of the affected payments and let us know:
1. what country the customer was from
2. the order currency
3. (important!) which payment method was actually used in PayPal, for example Sofort, Venmo, Pay Later, EPS, SEPA, Bancontact, card, PayPal balance, etc.
4. whether Product Page Checkout Buttons and Cart Page Checkout Buttons are enabled in your PayPal Commerce settings or you are sure the customer went through the normal full checkout flow
5. whether the cart had products requiring shipping, digital products, or both

The payment method is especially important because, depending on the method, the customer may even be asked to scan a QR code and complete the payment on their phone, so it is crucial to know which payment method was used.

The payment method can be visible in the PayPal transaction details. You can also check the logs in your PayPal developer account at developer.paypal.com to see if there are related API or webhook records for those transactions.

Once we know these details, it will be much easier to reproduce or narrow down where the checkout flow is breaking.

#39

Extension Support / Re: Possible bug in USPS exten...

Last post by Heemet - May 19, 2026, 06:05:53 PM

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

[Background]

#40

Extension Support / [Possible Bug + Fixes] PayPal ...

Last post by RCodiaDavid - May 19, 2026, 01:16:38 PM

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

Code Select Expand

$this->session->data['fc'] = array_merge($order->data, $this->session->data['fc']);
Replace with:

Code Select Expand

$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 Expand

          $order->buildOrderData($this->session->data['fc']);
                $order->saveOrder();
            }

        } catch (Exception|Error $e) {
Replace with:

Code Select Expand

          $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 Expand

      $mdl->savePaypalCustomer($this->customer->getId(), $transactionDetails['payer']['payer_id']);
            $mdl->savePaypalOrder(
                $orderId,
                [
                    'id'             => $transactionDetails['id'],
                    'transaction_id' => $transactionDetails['id'],
                ]
            );
Replace with:

Code Select Expand

      $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 Expand

  /** @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 Expand

  /** @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 Expand

   $this->data['pp']['purchase_units'][0] = [
            'reference_id' => $ppOrderData['data']['reference_id'] ? : $this->session->data['reference_id'],
            'amount'       => [Replace with:

Code Select Expand

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