OXID eShop bugtrack - Issues

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

Tue, 21 Jul 2026 17:22:37 +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.

0007981: Occasionally, the shop does not generate order emails

Tue, 21 Jul 2026 15:42:00 +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)

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.

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

Thu, 09 Jul 2026 09:28:01 +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.

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

Wed, 08 Jul 2026 17:02:18 +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 :)

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.

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

Wed, 08 Jul 2026 13:34:47 +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

Wed, 08 Jul 2026 10:26:46 +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

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.

0007973: Demodata - several Shippingcostrules has same sorting-position

Mon, 06 Jul 2026 14:02:09 +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.

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.

0007950: Oxobjectsrights has not complete subshop isolation or configration possibility

Fri, 03 Jul 2026 16:49:07 +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.

0007640: Module extending smarty-block visualcms_shortcodes_options breaks since 3.6.2

Thu, 02 Jul 2026 15:05:11 +0200

Since update to 3.6.2 a module overriding and loading parent with [{$smarty.block.parent}] breaks in line of $__label|addslashes|replace:'\\\'':'\''|oxescape where it cannot finde __label with such error message:

[uncaught error] [type E_USER_ERROR] [file [...]/vendor/smarty/smarty/libs/Smarty.class.php] [line 1099] [code ] [message Smarty error: [in ddoevisualcmsadmin.tpl line 140]: syntax error: unrecognized tag: $__label|addslashes|replace:'\\'':'\''|oxescape (Smarty_Compiler.class.php, line 440)]

This error with the same module doesn't occur in 3.6.1.

This error is only triggerd, if you use [{$smarty.block.parent}]

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.

0007743: In case a syntax error happens while Smarty renders a plain HTML template, the already fetched output gets echoed.

Wed, 01 Jul 2026 15:11:26 +0200

Behind the scene the output is buffered (ob_start), but if an exception is thrown, the output gets flushed (https://www.php.net/manual/en/outcontrol.output-handlers.php) and displays the content. In case of the password forgot plain HTML it displays the link to change the password. This allows an attacker to change the password of any account without a notice.

It’s necessary to have an error inside the the CMS page oxupdatepassinfoplainemail to be able to abuse the password forgot functionality.

Since every plain HTML template is buffered, this issue affects any plain HTML template.

0007967: Double-Encoded Quotes in Tag (Search Results Page) - in Twig-Templates</h1> <p>Wed, 01 Jul 2026 10:34:26 +0200</p> FrontendController::getPageTitle() calls the private method replaceDoubleQuotesWithHTMLCharacters(), which replaces " with ".<br /> This is a Smarty-era relic: back then the title was rendered without auto-escaping, so the entity had to be produced manually.<br /> <br /> Under Twig, however, the <title> tag (and og:title) is auto-escaped. As a result the ampersand gets encoded a second time:<br /> <br /> " -> " -> the browser tab literally displays ".<br /> <br /> This is most visible on the search results page, where the title wraps the search term in double quotes (e.g. Search results for "term"). The <h1> heading is not affected, because it is built with literal quotes in the template and is therefore auto-escaped only once. </article> <article> <h1>0007647: Allow non deprecated monolog versions ("^2.9||^3.0")</h1> <p>Wed, 01 Jul 2026 08:05:50 +0200</p> Some up to date php packages (e.g. from google) are dropping support for 1.x monolog dependency)<br /> =><br /> Your requirements could not be resolved to an installable set of packages.<br /> ...<br /> google/apiclient[v2.15.0, ..., v2.16.0] require monolog/monolog ^2.9||^3.0 -> satisfiable by monolog/monolog[2.9.0, 2.9.1, 2.9.2, 2.9.3, 3.0.0, ..., 3.6.0].<br /> oxid-esales/oxideshop-metapackage-ce v6.5.2 requires monolog/monolog 1.27.1 -> satisfiable by monolog/monolog[1.27.1] </article> <article> <h1>0007849: When Deactivating Module (e.g. PPC or Amazon) you got an exception: OXID Logger.ERROR: Template "module_main" nicht gefunden</h1> <p>Tue, 30 Jun 2026 13:37:59 +0200</p> Activating and deactivating each module individually works. Just not in sequence.<br /> <br /> This is where the error is triggered:<br /> vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(438)<br /> -> protected function render($view)<br /> <br /> try {<br /> $output = $renderer->renderTemplate($templateName, $viewData);<br /> } catch (\Throwable $exception) {<br /> <br /> It only happes when Deaktivating Module Amazon and PayPal, not Adyen. </article> <article> <h1>0007936: Security: Unauthorized Account Access</h1> <p>Mon, 29 Jun 2026 14:01:13 +0200</p> An authentication bypass (CWE-287) in the user authentication flow of the OXID PayPal checkout module allows a remote, unauthenticated attacker to access arbitrary customer accounts.<br /> <pre><br /> Affected versions (verified):<br /> >= 1.0.0, < 1.3.13<br /> >= 2.0.0, < 2.8.4<br /> >= 3.0.0, < 3.7.4<br /> <br /> Fixed versions:<br /> >= 1.4.0<br /> >= 2.9.0<br /> >= 3.8.0 </article> <article> <h1>0007961: If shop is running in Netto Mode, Stripe may charge an extra cent due to rounding differences</h1> <p>Thu, 25 Jun 2026 14:36:23 +0200</p> If shop is running in Netto Mode, Stripe may charge an extra cent due to rounding differences </article> </main></body></html>