OXID eShop bugtrack - Issues

0007073: Left entries from the popup "Assign article" in the category management do not disappear after assignment

Fri, 21 Aug 2026 13:27:59 +0200

If you move articles in the popup from the left column "All articles" to the right column "Articles in this category" under Categories->Master->"Assign articles", this article will not disappear from the left column.

0007979: smarty-to-twig-converter

Thu, 20 Aug 2026 12:20:32 +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 %}

0007113: Module information is not deleted completely

Thu, 20 Aug 2026 12:19:18 +0200

If a registered module is not present in modules directory, a question is displayed:
Invalid modules were detected. Do you want to delete all registered module information and saved configurations?
Answering "yes" does not update configuration file, so the message appears again and again.

0007978: login token for admin and frontend user

Thu, 20 Aug 2026 11:20:48 +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

0007998: Hidden dependency in the b2b-scheduled-orders-module for the b2b-offers-module

Thu, 20 Aug 2026 09:18:18 +0200

The `b2b-scheduled-orders-module` calls the `hasOffer` basket method twice:

b2b-scheduled-orders-module/Service/Service.php:163: if ($basket->hasOffer()) {
b2b-scheduled-orders-module/Controller/ApprovalDetailsController.php:87: if ($basket->hasOffer()) {

But this method is defined in `b2b-offers-module` which is not a dependency of `b2b-scheduled-orders-module`.

So either:
1. add `b2b-offers-module` as dependency of `b2b-scheduled-orders-module`
2. or check that the method `hasOffer` exists before calling it

0007985: Refund - send Mail

Thu, 20 Aug 2026 08:08:19 +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

0007311: User remains logged in when switching between subshobs, although "Allow users from other stores" is disabled

Wed, 19 Aug 2026 15:05:34 +0200

If the user is logged in to one shops and switches to another subshop, he is always logged in there as well, even though the "Master Settings > Core Settings > Shop 1 > Mall > Allow users from other shops" setting is not set, which is the default.

0005930: System health check should also check if folder for default cache backend on filesystem has sufficient permissions

Wed, 19 Aug 2026 14:42:37 +0200

Should be added to Files/folders access rights, otherwise Default Cache Backend can be activated, but will just provide nonsense.

Or, additionally, when activating Default Cache Backend, or changing Filesystem foldername, a check should verify if folder exists and if permissions are sufficient.

0007604: The manufacturer name in the article page doesn't change due to cache reasons

Wed, 19 Aug 2026 14:22:07 +0200

If you change the manufacturer of a product while default backend cache is configured, the manufacturer name on the product details page doesn't change

0007630: After submitting the contact form, input values remain, so some people may submit the form twice

Tue, 18 Aug 2026 13:09:07 +0200

After submitting the contact form, input values remain, so some people may submit the form twice. There is a little information on top: "Thank you. OXID eShop appreciates your comments."
But this can easily be overlooked and the form is not empty, which is unusual behavior.

0004420: Discount title didn't change in basket

Fri, 14 Aug 2026 11:12:48 +0200

Discount title didn't change in basket when changing languages.

0006352: Validation Registration E-Mail is inconsistent

Thu, 13 Aug 2026 17:54:32 +0200

oxMailValidator::isValidEmail is using a preg_match with an inconsistence regex "eMailRule".

Better use php standard email validation:
filter_var($email_a, FILTER_VALIDATE_EMAIL)
http://php.net/manual/de/filter.examples.validation.php

0007992: Add a Twig Variable Library to the Visual CMS that provides an overview of all available Twig variables and functions for easier

Wed, 12 Aug 2026 15:17:48 +0200

The Visual CMS should include a built-in Twig Variable Library that serves as a reference for content editors and developers.

The library should:

Display all available Twig variables and functions.
Provide a short description of each variable/function.
Include usage examples.
Optionally allow users to insert variables directly into the editor.
Improve productivity and reduce errors caused by incorrect or unknown Twig variables.

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

Wed, 12 Aug 2026 12:07:51 +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.

0007990: Metapackage requests insecure composer version during installation

Wed, 12 Aug 2026 08:04:18 +0200

During
composer create-project --no-dev oxid-esales/oxideshop-project htdocs dev-b-7.4-ee
OR
composer create-project --no-dev oxid-esales/oxideshop-project htdocs dev-b-7.4-pe
OR
composer create-project --no-dev oxid-esales/oxideshop-project htdocs dev-b-7.4-ce

this error occurs

oxid-esales/oxideshop-metapackage-ce v7.4.1 requires composer/composer 2.9.8 -> found composer/composer[2.9.8] but these were not loaded, because they are affected by security advisories ("PKSA-q3ht-3g42-rg8f", "PKSA-4pm6-g63v-5rkr", "PKSA-zcdk-qnhk-hq2g"). Go to https://packagist.org/security-advisories/ to find advisory details. To ignore the advisories, add them to the audit "ignore" config. To turn the feature off entirely, you can set "block-insecure" to false in your "audit" config.

0007770: Cant use admin with cloudflare domain because of endless redirects

Tue, 11 Aug 2026 16:44:21 +0200

As an oxid developer I want to be able to use the cloudflare domains like rene.oxiddev.de and the admin interface during development.

When i enter the url https://rene.oxiddev.de/admin the browser gets redirected endlessly. During debug I found this function:

OxidEsales\EshopCommunity\Core\Config::checkSsl

(oxideshop/vendor/oxid-esales/oxideshop-ce/source/Core/Config.php:781)

I think the last statement

```
if (
isset($serverVars['HTTP_X_FORWARDED_SERVER']) &&
(strpos($serverVars['HTTP_X_FORWARDED_SERVER'], 'ssl') !== false ||
strpos($serverVars['HTTP_X_FORWARDED_SERVER'], 'secure-online-shopping.de') !== false)
) {
$this->setIsSsl(true);
}
```

could be extended with

```
|| isset($serverVars['HTTP_X_FORWARDED_PROTO']) && $serverVars['HTTP_X_FORWARDED_PROTO'] == 'https'
```

When i use cloudflare this header is always set to https when using https. So my propsal would be to include this check to be able to use cloud flare domains.

0007993: Ascending and descending sort order for every admin list

Tue, 11 Aug 2026 11:04:39 +0200

As already mentioned in https://bugs.oxid-esales.com/view.php?id=1405, but unfortunately not implemented,
the sorting function in all admin lists is extremely user-unfriendly because it only works in one direction ( ascending ).

With a small adjustment of the getSorting() function, switching the sort direction should be easy to implement
and would significantly improve handling in the backend!

0007991: SQL Injection via getRequestEscapedParameter() via Admin

Mon, 10 Aug 2026 19:43:40 +0200

getRequestEscapedParameter() doesnt escape parameters if its used in admin focus so some functions allow sql injections especially if used in combination with
$database = \OxidEsales\Eshop\Core\DatabaseProvider::getDb();

Example:
htdocs/vendor/oxid-esales/oxideshop-ee/Application/Controller/Admin/ArticleRightsBuyableAjax.php
htdocs/vendor/oxid-esales/oxideshop-ee/Application/Controller/Admin/AttributeCategoryAjax.php

and more

0007963: PayPal smart button: terms-and-conditions check runs inside createOrder instead of onClick

Fri, 31 Jul 2026 12:17:10 +0200

On the order step ("Jetzt kaufen" / step 4), clicking the PayPal button without confirming the terms-and-conditions checkbox makes the PayPal popup open briefly and close again.
The browser console shows:
Uncaught Error: Expected an order id to be passed (thrown by PayPal JS SDK v5.0.556, paypal.com/smart/buttons).

Root cause
The standard PayPal button (

from checkout_order_btn_submit_bottom.tpl) is rendered by standard-payment-controller.js. The terms check (checkTermsAndConditions()) exists, but it runs inside createOrder and, on failure, does a bare return; — i.e. createOrder resolves to undefined. Since the PayPal SDK opens the popup synchronously on click and only then calls createOrder, an undefined return triggers the SDK's strict order-id check, which surfaces as the visible error and a popup that closes immediately. getPayButtonSettings() defines no onClick handler, so there is no pre-flight rejection.

Correct behaviour (existing reference)
Apple Pay (applepay.tpl) and Google Pay (googlepay-payment-controller.js) already perform the check before the payment flow starts — in the click handler / onClick, returning early / actions.reject() so the popup never opens.

Affected
- standard-payment-controller.js — check in createOrder instead of onClick (primary, matches the report).
- acdc-payment-controller.js — same pattern (check inside order creation rather than onClick).
- paymentbuttons.tpl (Express / SEPA / CC funding buttons) — no terms check at all; separate but same failure class.

Fix direction
Add an onClick(data, actions) pre-check to the PayPal/ACDC button settings that calls checkTermsAndConditions(), shows READ_AND_CONFIRM_TERMS and rejects (actions.reject()) before the popup opens; keep createOrder as a safety net. Mirror the same pre-check into the funding buttons in paymentbuttons.tpl. To be fixed in the OXID 6 and OXID 7 module lines.

0007959: The PayPal Express button disappears from the shopping cart when changes are made to the item quantity

Fri, 31 Jul 2026 12:16:26 +0200

If you change the quantity of an item directly in the shopping cart using the minus/plus icon, the PayPal Express button will disappear from the shopping cart.

This issue only affects the OXID 7 version.
It cannot be reproduced in OXID 6.5 with v2.9.1.

0007962: PayPal Checkout ignores paymentId when basket already contains another payment method

Fri, 31 Jul 2026 12:15:53 +0200

When using PayPal Checkout, the PayPal module passes the correct payment ID oscpaypal to the shop order creation process. However, if the basket already contains another payment method, for example oxidamazon, the PayPal payment ID is ignored and the order is created with the previously stored basket payment method.

Relevant code path:
```
// vendor/oxid-solution-catalysts/paypal-module/src/Controller/AjaxPaymentController.php:109

$paymentId = $data['paymentId'] ?? null;

$this->orderManager->createShopOrder($paymentId);
```

Inside createShopOrder(), the PayPal payment method is only set if the basket currently has no payment method assigned:

```
// vendor/oxid-solution-catalysts/paypal-module/src/Service/OrderManager.php:75

if (empty($this->basket->getPaymentId()) && !empty($paymentId)) {
$this->basket->setPayment($paymentId);
}
```

If the basket already contains oxidamazon, the provided PayPal payment ID is ignored.

The OXID order then uses the payment method directly from the basket:

```
// vendor/oxid-esales/oxideshop-ce/source/Application/Model/Order.php:515

$oUserPayment = $this->_setPayment($oBasket->getPaymentId());
```

As a result, the created order contains:

```
OXPAYMENTTYPE = oxidamazon
```

although the customer actually completed the checkout using PayPal.

At the same time, the PayPal Checkout flow sets a special session flag:

```
// vendor/oxid-solution-catalysts/paypal-module/src/Service/OrderManager.php:82

$session->setVariable('isPayPalPaymentCheckout', true);
```

This flag causes the regular payment execution to be skipped:

```
// vendor/oxid-solution-catalysts/paypal-module/src/Model/Order.php:413

if (Registry::getSession()->getVariable('isPayPalPaymentCheckout')) {
return true;
}
```

OXID interprets this true return value as a successful payment and sets the order status to OK:

```
// vendor/oxid-esales/oxideshop-ce/source/Application/Model/Order.php:552

$this->_setOrderStatus('OK');
```

Only after the OXID order has already been created, the PayPal module changes the basket payment method to PayPal:

```
// vendor/oxid-solution-catalysts/paypal-module/src/Controller/AjaxPaymentController.php:130

$this->setPayPalPaymentMethod(
PayPalDefinitions::STANDARD_PAYPAL_PAYMENT_ID
);
```

This happens too late for the already created OXID order.

Expected behavior:

When PayPal Checkout is used, the order should be created with the PayPal payment method, for example:

`OXPAYMENTTYPE = oscpaypal`

The PayPal payment ID passed to createShopOrder($paymentId) should overwrite any previously stored basket payment method for this checkout flow.

Actual behavior:

If the basket already contains another payment method, for example oxidamazon, the order is created with: `OXPAYMENTTYPE = oxidamazon`

even though the customer used PayPal Checkout. The order is then marked as OK because the PayPal Checkout session flag skips the normal payment execution.

Possible fix:

In the PayPal Checkout flow, createShopOrder($paymentId) should set the provided payment ID whenever it is present, not only when the basket payment ID is empty.

Current logic:

```
if (empty($this->basket->getPaymentId()) && !empty($paymentId)) {
$this->basket->setPayment($paymentId);
}
```
Possible adjusted logic:

```
if (!empty($paymentId)) {
$this->basket->setPayment($paymentId);
}
```

This would ensure that the order is created with the payment method actually used in the checkout.

0007964: When attempting to pay with PayPal, a maintenance page appears in the store, likely due to a lost session

Fri, 31 Jul 2026 12:15:16 +0200

When attempting to pay via PayPal, a maintenance page appeared in the shop.

The cause is likely a lost session.

The shop (7.2.0) is using version 3.7.4 of the module. However, I can reproduce the same behavior up to version 3.8.2 RC.

0007849: When Deactivating Module (e.g. PPC or Amazon) you got an exception: OXID Logger.ERROR: Template "module_main" nicht gefunden

Fri, 31 Jul 2026 12:14:05 +0200

Activating and deactivating each module individually works. Just not in sequence.

This is where the error is triggered:
vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(438)
-> protected function render($view)

try {
$output = $renderer->renderTemplate($templateName, $viewData);
} catch (\Throwable $exception) {

It only happes when Deaktivating Module Amazon and PayPal, not Adyen.

0007989: Refund - send Mail

Thu, 30 Jul 2026 15:43:49 +0200

0007988: Refund - send Mail

Thu, 30 Jul 2026 15:42:30 +0200