OXID eShop bugtrack - Issues

0007982: oe:license:add silently stores nothing on an offline (grace-expired / unlicensed) shop

Wed, 29 Jul 2026 15:04:54 +0200

A shop whose license grace period has expired serves the maintenance/offline page (HTTP 500) and considers itself unlicensed. Attempting to recover it with oe:license:add appears to succeed but stores nothing:

- The command prints only Adding new license, exits 0, and prints no status line and no error.
- Reading the database directly shows aSerials remains a:0:{} (empty) before and after the command.

Root cause: the shop-validity/offline check runs during config load, triggered by the very first getConfigParam() call. When the license is invalid, this check terminates the process with a clean exit() (no PHP error). oe:license:add internally reads config (validate() then getSerialList() then getConfigParam('aSerials')) as its first config access, so it is killed before it reaches the code that persists the serial. The shop therefore cannot license itself via the console once it has gone offline.

0007973: Demodata - several Shippingcostrules has same sorting-position

Wed, 29 Jul 2026 08:20:54 +0200

In the demo data, some shipping cost rules share the same sort position; specifically, position "0" has been assigned twice. The "first" shipping cost rule holds special significance: if a customer is not logged in, shipping costs can still be calculated during checkout, with the shop applying the first applicable rule. This duplicate assignment can cause shipping costs to fluctuate during checkout. Payment modules with express functionality sometimes fail to display shipping costs consistently.

0007984: Refund - send Mail

Tue, 28 Jul 2026 14:16:34 +0200

There is no email notification indicating when a refund is processed in the admin panel.

Add a function to send an email t the customer.
Add an additional checkbox next to "Refund all."

Content:
"A refund has been initiated.
You can find further information in your PayPal account or the PayPal app."

-----
D3/MG

0007983: Automatic login (same feature as with PayPal)

Tue, 28 Jul 2026 09:44:52 +0200

This feature is already implemented in the current PayPal module.
In Settings -> Automatic Login -> you can enable the following setting:
Log in automatically to the shop when making a purchase
If the shop customer account email address is the same as the PayPal email address, it is possible to log in automatically to the shop by logging in to PayPal.

0007976: Adyen-Module :: PaymentGatewas-Service: autorized Amount

Mon, 27 Jul 2026 17:28:33 +0200

For payments processed through the payment provider Adyen, an Oxid Shop EE (v 7.5) with the Adyen module (https://github.com/OXID-eSales/adyen-module v 2.1.10, SDK version 5.27.0) is used.
We noticed a discrepancy with an order placed via Adyen using Klarna: The customer had authorized an amount lower than the actual order value in Adyen, but the module displayed the full amount as authorized in the admin order overview.
Two-step capture is used here because orders placed via Klarna are not captured until the goods leave the warehouse.
That is why the error was not noticed until then.

0005590: oxUtilsFile does not "grow" with iPicCount-Config

Mon, 27 Jul 2026 15:32:04 +0200

If you change the iPicCount-Config oxUtilsFile::iMaxPicImgCount and oxUtilsFile::iMaxZoomImgCount are changed through __construct(). But _aTypeToPath is not changed in the same way and the image is moved to the "0" dir. This is not a correct behavior. You need to create a module of oxUtilsFile for clean behaviour without it oxArticle::getPictureUrl() does not work correctly (for example).

0007950: Oxobjectsrights has not complete subshop isolation or configration possibility

Mon, 27 Jul 2026 13:01:54 +0200

It is possible to create a rule and edit it in another sub-shop; however, the rule will continue to apply only in the original shop where it was created.

0007965: Apple Pay (via the PayPal module) apparently only works with Safari

Fri, 24 Jul 2026 09:57:17 +0200

The Apple Pay button appears in the final step of checkout only if you're using Safari.

According to Heise.de, however, it should work with any browser:
https://www.heise.de/news/iOS-16-Apple-fuegt-heimlich-Apple-Pay-Unterstuetzung-fuer-andere-Browser-hinzu-7196342.html

a) The module supports Apple Pay in conjunction with Firefox, Chrome, etc.
b) The module should not offer this payment method at all in Firefox, Chrome, etc.

0007981: Occasionally, the shop does not generate order emails

Fri, 24 Jul 2026 09:55:48 +0200

Since updating the module to vv2.9.1, I’ve already encountered the problem on two orders where no order emails were generated by the shop (neither for the shop nor for the customer)

0007954: For PayPal orders, the oxtrackcode is not saved in the oxorder table

Fri, 24 Jul 2026 09:16:37 +0200

If you enter the oxtrackcode in the admin panel, it is not saved in the oxorder_oxtrackcode table for PayPal orders.
As a result, the tracking ID is no longer displayed to the customer in the frontend -> Order History.

0007974: Fix type cast in PaymentGateway::executePayment

Thu, 23 Jul 2026 23:05:09 +0200

In the executePayment method of the PaymentGateway class, the return value from getSessionPaymentId() was not explicitly cast to a string. This led to fatal errors when using the method PayPalDefinitions::isButtonPayment with a null value in situations where no session is available, e.g., when calling executePayment for other modules in CLI scenarios.

public function executePayment($amount, &$order)
{
$paymentService = $this->getServiceFromContainer(PaymentService::class);
// patch start
// $sessionPaymentId = $paymentService->getSessionPaymentId();
$sessionPaymentId = (string) $paymentService->getSessionPaymentId();
// patch stop

0007975: Javascript Fehler "Can't find variable: ApplePayPaymentController"

Thu, 23 Jul 2026 22:58:21 +0200

Laut unseren Logs tritt der Fehler im vierten Bestellschritt (cl=order) auf und wird durch https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/views/tpl/shared/applepay.tpl#L430 ausgelöst.

Die Ursache liegt dabei in der Minifizierung von https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/resources/build/js/paypal-frontend-applepay-payment-controller.js

In https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/out/src/js/paypal-frontend.min.js ist aus der paypal-frontend-applepay-payment-controller.js das hier geworden.

(
()=>{
function e(e){
return PayPalPaymentControllerBase.call(this,e),this.resetCurrentOrder(),this
}

window.addEventListener("load",function(){
void 0===window.PayPalPayment&&void 0!==window.ApplePayPayPalPaymentControllerConfiguratorDefaults&&(window.PayPalPayment=new e)
})
})
()

Der Funktionsname ApplePayPaymentController wurde also gefressen und steht dem Template oben nicht mehr zur Verfügung.

Lustigerweise scheint der Fehler aber keine Auswirkung auf den eigentlichen Bestellabschluss zu haben, da die betroffenen Kunden ihre ApplePay Bestellung ungehindert abschließen können. Daher das Thema hier mal als kleinen Fehler eingestuft, der uns nur in den Logs auf die Nerven geht :)

0007980: Many cancelled orders with the current paypal checkout module version

Thu, 23 Jul 2026 21:07:48 +0200

We frequently encounter situations where customers are unable to complete their orders, which are then automatically cancelled by the PayPal checkout module.
According to customers, after BS4 the browser ‘hangs’ for a very long time and nothing happens, until the customers eventually cancel the process themselves.

It is striking that customers really do try several times and fail repeatedly, and presumably wait a very long time for a response from the browser during the subsequent steps.
This happens regardless of whether they use the standard ‘PayPal’ option or the ‘Credit Card’ option, which also runs via PayPal Checkout.

0007395: It's not possible to set the telephone number oxfon

Thu, 23 Jul 2026 14:02:06 +0200

The table oxuser has three fields for telephone numbers:
- oxfon
- oxprivfon
- oxmobfon

The mutation customerRegister doesn't offer to set those fields, but the mutation customerInvoiceAddressSet. Though it only allows to change the phone and mobile number.

Conclusion: Currently it's only possible to set oxprivfon and oxmobfon, but not oxfon.

0007153: Input field length for SMTP password is too small

Thu, 23 Jul 2026 12:19:53 +0200

I had to configure a SMTP connection with a long password. After entering the password in OXID admin, I got an "Authentication failed" error.

After some investigation I found this issue:

I used the password "ThisIsALongPassword.TooLongForThisInputField,ButNotTooLongForTheDB." and entered into the "SMTP password" input field in OXID admin (Attachment 1). After clicking "Save" only "ThisIsALongPassword.TooLongForThisInputField,ButNo" was stored to the DB (Attachment 2).
I edited the HTML to see what is inside the input field and I found out it's already truncated (Attachment 3).

There are two different definitions of maximum field length for the SMTP password (and maybe for other fields too). In MySQL it is defined as "VARCHAR(128)", so it could be 128 characters long.

0007979: smarty-to-twig-converter

Fri, 17 Jul 2026 15:41:05 +0200

Der Smarty-to-Twig-Converter konvertiert die folgende Zeile falsch:
[{assign var="webconnectFileMTime" value=$oViewConf->getModulePath('oxps/webconnect', 'out/src/js/webconnecterp_productlists.js')|filemtime}]

Diese Zeile wird übersetzt zu:
{% set webconnectFileMTime = oViewConf.getModulePath('oxps/webconnect', %}

Erwartete Ausgabe:
{% set webconnectFileMTime = oViewConf.getModulePath('oxps/webconnect', 'out/src/js/webconnecterp_productlists.js')|filetime %}

0007978: login token for admin and frontend user

Thu, 16 Jul 2026 13:55:42 +0200

- In our project we have an impersonation feature that lets an admin user load a frontend user and place orders on their behalf. This worked fine up to OXID 7.0.
- OXID 7.4 introduced a login-token mechanism (in UserComponent and in User::loadActiveUser()): on login a hash derived from the user's password hash is stored in the session under a single key login-token, and on every loadActiveUser() call it is re-verified against the current password hash — if it doesn't match, the user is logged out.
- This breaks impersonation, because the core uses one shared login-token key for both the admin (backend) and the frontend user, distinguished only at runtime via isAdmin(). With admin and frontend logged in in parallel within the same session, whichever context writes the token last overwrites the other, so the other context fails the check and gets logged out.
- I've worked out a workaround that splits the token into two context-specific session slots (login-token-admin / login-token-frontend) and translates between them and the generic login-token key the core expects, leaving the actual verifyHash check untouched.
- My concern: this relies on the internal login-token key name and the way the core reads/writes it. If a future OXID version renames the key, changes where it's set, or alters the verification flow, the workaround will silently break.
- Question: is the login-token handling considered stable/public API, or is it an internal implementation detail that may change? And is there an officially supported extension point for impersonation-style parallel sessions that I should use instead?

Thanks

0007977: With Unzer, an error is thrown when the thank-you page appears, and an email is not sent

Fri, 10 Jul 2026 08:04:15 +0200

Unzer Module v 2.2.7
However, the order is created

0007960: "Shipped" status is incorrectly displayed for every non-cancelled order.

Thu, 09 Jul 2026 11:10:25 +0200

- Component: oxid-esales/apex-theme v3.1.0 (additionally oxid-esales/twig-theme)
- File/Line: tpl/page/account/order.html.twig:32 (Apex) or :26 (Wave)
- Error: Comparison `oxsenddate.value != " - "` uses spaces instead of `!= "-"`. `formatDBDate()` returns `'-'` (without spaces) for unshipped orders, so the condition is always true
- "Shipped" status is incorrectly displayed for every non-cancelled order.

0007968: The assignment windows do not display any data anymore

Wed, 08 Jul 2026 15:08:47 +0200

With "assignment window" i mean the small windows that open after you click something like the "assign countries to a payment method" or "assign categories to a product" buttons.
After we updated to Oxid metapackage-ee version 7.5 these assignment windows stop displaying any data.

This seems to happen because the the Core/Config.php has been adjusted so that in the getConfigParam() does not call "init()" anymore. Instead it only calls "initVars()". This makes it so that the session does not get properly initialized in the source/oxajax.php anymore. For now we fixed it ourselves by directly calling Config->init() in oxajax.php.

0007953: No assignment of main category possible

Tue, 07 Jul 2026 16:48:00 +0200

it was possible to assign a main caegory.
this button doesn't work anymore. it stays disabled.

0007972: PayPal Webhook Fehler

Mon, 06 Jul 2026 10:05:57 +0200

Logik-Widerspruch im Code: Das Modul wirft intern völlig korrekt eine WebhookEventRetryException (da die Bestellung zum exakten Zeitpunkt des Webhook-Eingangs wegen DB-Transaktionen/Race-Conditions noch nicht vollständig geladen werden kann).

Fehlerhaftes HTTP-Handling: Anstatt diese Retry-Exception zu nutzen, um PayPal über einen HTTP-Statuscode 422 oder 503 mitzuteilen, dass der Request später wiederholt werden soll, fängt das Modul (oder der OXID-Core) die Exception ab und antwortet mit einem HTTP 200 OK.

Die Folge: PayPal hakt den Webhook als "erfolgreich zugestellt" ab und sendet ihn nie wieder. Dem Shop fehlen dadurch dauerhaft die Zahlungs- und Bankdaten für den Rechnungskauf.

0007969: text widget doesn't support twig codes/variables.

Thu, 02 Jul 2026 13:57:41 +0200

In the text widget you cannot have information like {{ oxcmp_shop.oxshops__oxname.value }}
the old oxcontent in plaintextmode (oxcontents__ddplaintext) still support those, but if used in text widget they get discarded.

0007971: Checking B2B mode differs between the module and the shop

Thu, 02 Jul 2026 13:02:53 +0200

In the PayPal module, the B2B mode is always checked via the shop’s basic settings: Registry::getConfig()->getConfigParam(“blShowNetPrice”).

In the shop, the basket object has a method for checking the B2B mode: isPriceViewModeNetto().

If you had to build a B2B module, you would overload this method.
However, this only makes sense if you actually use it in your module.

0007970: Cleaning up the use of the orphaned variable $withItems

Thu, 02 Jul 2026 13:01:58 +0200

Cleaning up the use of the orphaned variable $withItems
The two instances of $withItems:
- OrderRequestFactory::getRequest();

You had already removed the usage here. If you also remove the orphaned variable, it will be less confusing.

- PatchRequestFactory::getPurchaseUnitsPatch();
Here, the status is still being retrieved and actively used.