0007972: PayPal Webhook Fehler

Wed, 01 Jul 2026 17:17:42 +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.

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.

0007950: Oxobjectsrights has not complete subshop isolation or configration possibility

Wed, 01 Jul 2026 15:07:10 +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.

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

Wed, 01 Jul 2026 13:17: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.

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>0007968: The assignment windows do not display any data anymore</h1> <p>Wed, 01 Jul 2026 09:02:55 +0200</p> 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.<br /> After we updated to Oxid metapackage-ee version 7.5 these assignment windows stop displaying any data. <br /> <br /> 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. </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>0007971: Checking B2B mode differs between the module and the shop</h1> <p>Tue, 30 Jun 2026 15:27:37 +0200</p> In the PayPal module, the B2B mode is always checked via the shop’s basic settings: Registry::getConfig()->getConfigParam(“blShowNetPrice”).<br /> <br /> In the shop, the basket object has a method for checking the B2B mode: isPriceViewModeNetto().<br /> <br /> If you had to build a B2B module, you would overload this method. <br /> However, this only makes sense if you actually use it in your module. </article> <article> <h1>0007970: Cleaning up the use of the orphaned variable $withItems</h1> <p>Tue, 30 Jun 2026 15:19:24 +0200</p> Cleaning up the use of the orphaned variable $withItems<br /> The two instances of $withItems:<br /> - OrderRequestFactory::getRequest();<br /> <br /> You had already removed the usage here. If you also remove the orphaned variable, it will be less confusing.<br /> <br /> - PatchRequestFactory::getPurchaseUnitsPatch();<br /> Here, the status is still being retrieved and actively used. </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> <article> <h1>0007954: For PayPal orders, the oxtrackcode is not saved in the oxorder table</h1> <p>Thu, 25 Jun 2026 13:09:54 +0200</p> If you enter the oxtrackcode in the admin panel, it is not saved in the oxorder_oxtrackcode table for PayPal orders.<br /> As a result, the tracking ID is no longer displayed to the customer in the frontend -> Order History. </article> <article> <h1>0007965: Apple Pay (via the PayPal module) apparently only works with Safari</h1> <p>Thu, 25 Jun 2026 12:18:26 +0200</p> The Apple Pay button appears in the final step of checkout only if you're using Safari.<br /> <br /> According to Heise.de, however, it should work with any browser:<br /> <a href="https://www.heise.de/news/iOS-16-Apple-fuegt-heimlich-Apple-Pay-Unterstuetzung-fuer-andere-Browser-hinzu-7196342.html" rel="noopener,nofollow">https://www.heise.de/news/iOS-16-Apple-fuegt-heimlich-Apple-Pay-Unterstuetzung-fuer-andere-Browser-hinzu-7196342.html</a><br /> <br /> a) The module supports Apple Pay in conjunction with Firefox, Chrome, etc.<br /> b) The module should not offer this payment method at all in Firefox, Chrome, etc. </article> <article> <h1>0007960: "Shipped" status is incorrectly displayed for every non-cancelled order.</h1> <p>Wed, 24 Jun 2026 08:34:30 +0200</p> - Component: oxid-esales/apex-theme v3.1.0 (additionally oxid-esales/twig-theme)<br /> - File/Line: tpl/page/account/order.html.twig:32 (Apex) or :26 (Wave)<br /> - Error: Comparison `oxsenddate.value != " - "` uses spaces instead of `!= "-"`. `formatDBDate()` returns `'-'` (without spaces) for unshipped orders, so the condition is always true <br /> - "Shipped" status is incorrectly displayed for every non-cancelled order. </article> <article> <h1>0007964: When attempting to pay with PayPal, a maintenance page appears in the store, likely due to a lost session</h1> <p>Fri, 19 Jun 2026 10:19:46 +0200</p> When attempting to pay via PayPal, a maintenance page appeared in the shop.<br /> <br /> The cause is likely a lost session.<br /> <br /> 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. </article> <article> <h1>0007934: Console Tools: oe-console commands incorrectly return exit code 0 on failure</h1> <p>Wed, 17 Jun 2026 15:15:53 +0200</p> Four console commands in the OXID eShop CLI (vendor/bin/oe-console) do not signal failure via the exit code. They terminate with exit code 0 (success) even though the operation failed. The error is printed to STDOUT as <error>...</error>, but the exit code remains 0.<br /> <br /> This is problematic for:<br /> - CI/CD pipelines: Build scripts cannot detect failures and continue executing even when, for example, a license was not installed.<br /> - Shell scripts: Constructs like command && next-step or set -e do not work reliably. <br /> - Automation: Provisioning tools (Ansible, Docker setup scripts, Make targets) cannot handle failures correctly.<br /> <br /> Affected commands and code locations<br /> - oe:license:add<br /> - oe:module:activate<br /> - oe:module:deactivate<br /> - oe:setup:demodata </article> <article> <h1>0007933: Console Tools: Incorrect output for --version</h1> <p>Wed, 17 Jun 2026 15:14:21 +0200</p> When running "vendor/bin/oe-console --version", the command returns "Console Tool". It should display the actual version number instead. </article> <article> <h1>0007484: A translation error occurs after creating a new sub shop</h1> <p>Wed, 17 Jun 2026 15:13:05 +0200</p> The mall menu displays a translation key instead of the translated string. </article> <article> <h1>0007918: Misleading error message when Authorization header is stripped by Apache</h1> <p>Wed, 17 Jun 2026 15:08:40 +0200</p> Misleading error message when Authorization header is stripped by Apache<br /> <br /> When Apache strips the Authorization header before it reaches PHP (a common default configuration), all #[Logged] endpoints return:<br /> <br /> <br /> "You need to be logged to access this field"<br /> This is the same error message regardless of whether:<br /> <br /> No token was sent<br /> An invalid token was sent<br /> A valid token was sent but the header was stripped by the webserver<br /> <br /> <br /> The module should differentiate between:<br /> <br /> No Authorization header present use current anonymous fallback is acceptable<br /> Authorization header present but token invalid use specific error, e.g. "Invalid or expired token"<br /> Authorization header absent despite being expected use ideally a hint that the header may be stripped by the webserver<br /> At minimum, when a Bearer token is provided but cannot be parsed (because the header was silently dropped), the error should differ from the anonymous-user case.<br /> <br /> Suggested Improvements<br /> Documentation: Add the .htaccess RewriteRule to the installation docs as a required step for Apache environments. This is a well-known Apache/PHP issue but not obvious for OXID module developers debugging "You need to be logged" errors.<br /> <br /> Error differentiation: In RequestReader::getAuthToken(), if no Authorization header is found, check for REDIRECT_HTTP_AUTHORIZATION and HTTP_AUTHORIZATION server variables as fallback. If none are present, consider setting a flag that distinguishes "no auth attempted" from "auth attempted but failed".<br /> <br /> Environment<br /> OXID eShop 7.4.x<br /> graphql-base 12.0.1<br /> Apache with mod_rewrite (Docker SDK setup)<br /> PHP-FPM </article> <article> <h1>0007962: PayPal Checkout ignores paymentId when basket already contains another payment method</h1> <p>Sat, 13 Jun 2026 10:41:15 +0200</p> 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.<br /> <br /> Relevant code path:<br /> ```<br /> // vendor/oxid-solution-catalysts/paypal-module/src/Controller/AjaxPaymentController.php:109<br /> <br /> $paymentId = $data['paymentId'] ?? null;<br /> <br /> $this->orderManager->createShopOrder($paymentId);<br /> ```<br /> <br /> Inside createShopOrder(), the PayPal payment method is only set if the basket currently has no payment method assigned:<br /> <br /> ```<br /> // vendor/oxid-solution-catalysts/paypal-module/src/Service/OrderManager.php:75<br /> <br /> if (empty($this->basket->getPaymentId()) && !empty($paymentId)) {<br /> $this->basket->setPayment($paymentId);<br /> }<br /> ```<br /> <br /> If the basket already contains oxidamazon, the provided PayPal payment ID is ignored.<br /> <br /> The OXID order then uses the payment method directly from the basket:<br /> <br /> ```<br /> // vendor/oxid-esales/oxideshop-ce/source/Application/Model/Order.php:515<br /> <br /> $oUserPayment = $this->_setPayment($oBasket->getPaymentId());<br /> ```<br /> <br /> As a result, the created order contains:<br /> <br /> ```<br /> OXPAYMENTTYPE = oxidamazon<br /> ```<br /> <br /> although the customer actually completed the checkout using PayPal.<br /> <br /> At the same time, the PayPal Checkout flow sets a special session flag:<br /> <br /> ```<br /> // vendor/oxid-solution-catalysts/paypal-module/src/Service/OrderManager.php:82<br /> <br /> $session->setVariable('isPayPalPaymentCheckout', true);<br /> ```<br /> <br /> This flag causes the regular payment execution to be skipped:<br /> <br /> ```<br /> // vendor/oxid-solution-catalysts/paypal-module/src/Model/Order.php:413<br /> <br /> if (Registry::getSession()->getVariable('isPayPalPaymentCheckout')) {<br /> return true;<br /> }<br /> ```<br /> <br /> OXID interprets this true return value as a successful payment and sets the order status to OK:<br /> <br /> ```<br /> // vendor/oxid-esales/oxideshop-ce/source/Application/Model/Order.php:552<br /> <br /> $this->_setOrderStatus('OK');<br /> ```<br /> <br /> Only after the OXID order has already been created, the PayPal module changes the basket payment method to PayPal:<br /> <br /> ```<br /> // vendor/oxid-solution-catalysts/paypal-module/src/Controller/AjaxPaymentController.php:130<br /> <br /> $this->setPayPalPaymentMethod(<br /> PayPalDefinitions::STANDARD_PAYPAL_PAYMENT_ID<br /> );<br /> ```<br /> <br /> This happens too late for the already created OXID order.<br /> <br /> Expected behavior:<br /> <br /> When PayPal Checkout is used, the order should be created with the PayPal payment method, for example:<br /> <br /> `OXPAYMENTTYPE = oscpaypal`<br /> <br /> The PayPal payment ID passed to createShopOrder($paymentId) should overwrite any previously stored basket payment method for this checkout flow.<br /> <br /> Actual behavior:<br /> <br /> If the basket already contains another payment method, for example oxidamazon, the order is created with: `OXPAYMENTTYPE = oxidamazon`<br /> <br /> 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.<br /> <br /> Possible fix:<br /> <br /> 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.<br /> <br /> Current logic:<br /> <br /> ```<br /> if (empty($this->basket->getPaymentId()) && !empty($paymentId)) {<br /> $this->basket->setPayment($paymentId);<br /> }<br /> ```<br /> Possible adjusted logic:<br /> <br /> ```<br /> if (!empty($paymentId)) {<br /> $this->basket->setPayment($paymentId);<br /> }<br /> ```<br /> <br /> This would ensure that the order is created with the payment method actually used in the checkout. </article> <article> <h1>0007963: PayPal smart button: terms-and-conditions check runs inside createOrder instead of onClick</h1> <p>Fri, 12 Jun 2026 16:11:25 +0200</p> 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.<br /> The browser console shows:<br /> Uncaught Error: Expected an order id to be passed (thrown by PayPal JS SDK v5.0.556, paypal.com/smart/buttons).<br /> <br /> Root cause<br /> The standard PayPal button (<div id="oscpaypal"> 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.<br /> <br /> Correct behaviour (existing reference)<br /> 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.<br /> <br /> Affected<br /> - standard-payment-controller.js — check in createOrder instead of onClick (primary, matches the report).<br /> - acdc-payment-controller.js — same pattern (check inside order creation rather than onClick).<br /> - paymentbuttons.tpl (Express / SEPA / CC funding buttons) — no terms check at all; separate but same failure class.<br /> <br /> Fix direction<br /> 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. </article> <article> <h1>0006025: Add article to order, not article found</h1> <p>Fri, 12 Jun 2026 10:57:46 +0200</p> [Administer Orders] --> [Orders] --> [Tab: Products]<br /> --> search product<br /> <br /> The searchquery contains the fields (oxid, oxparentid) in lower case.<br /> But the script expect the field in Upper Case(OXId, OXPARENTID).<br /> <br /> In some cases(server, php-configuration, ..) this dosn't work.<br /> <br /> So, please use lower case or capitals and not a mix. </article> <article> <h1>0007959: The PayPal Express button disappears from the shopping cart when changes are made to the item quantity</h1> <p>Thu, 11 Jun 2026 12:28:14 +0200</p> 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.<br /> <br /> This issue only affects the OXID 7 version.<br /> It cannot be reproduced in OXID 6.5 with v2.9.1. </article> <article> <h1>0007893: AmazonPay Modul 2.6.x (b-6.3.x sowie b-7.0.x)</h1> <p>Thu, 11 Jun 2026 12:26:40 +0200</p> Wenn man in den yaml Dateien einen Leerstring einträgt, so werden keine Defaultwerte gesetzt.<br /> <br /> Beispiel:<br /> amazonPayCapType:<br /> type: str<br /> value: ''<br /> <br /> Die entsprechende Validierung des Wertes erfolgt in \OxidSolutionCatalysts\AmazonPay\Controller\Admin\ConfigController::handleSpecialFields<br /> Dort wird als Validierung eine !isset($conf['amazonPayCapType']) ausgeführt.<br /> <br /> Diese ist jedoch bei einem Leerstring immer false, da ein Leerstring als gesetzt zählt:<br /> php -r '$conf["foo"] = ""; var_dump(!isset($conf["foo"]));'<br /> <br /> Dadurch werden die Daten nicht korrekt gesetzt in der Configuration für AmazonPay. </article> </main></body></html>

OXID eShop bugtrack - Issues

0007972: PayPal Webhook Fehler

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

0007950: Oxobjectsrights has not complete subshop isolation or configration possibility

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