# 1.6.3
- Kompatibilität mit PHP 8.3 bis 8.5 unter Shopware 6.6 und 6.7 geprüft; Mindestversion von PHP auf 8.3 angehoben.
- Vollständige Abnahme (Installation aus dem ZIP, Konfiguration, Widgets, Ratenzahlung, Erstattung) unter PHP 8.5 auf Shopware 6.6.10 und 6.7.13 wiederholt. Der Plugin-Code erzeugt keine Deprecation. Nur das mitgelieferte Alma-SDK ruft noch `curl_close()` auf, das in PHP 8.5 als veraltet gilt und wirkungslos ist: eine Protokollzeile, keine funktionale Auswirkung.
- Abgeschnittene Texte in der Administration unter Shopware 6.7 behoben.
- Die Alma-Betragsgrenzen unter jedem Zahlungsplan („Alma limits: € - €“), die Details von Ladefehlern der Pläne sowie die Meldungen zu Erstattung, Verbindungstest und Schlüssel-Löschung verloren ihre Werte, da Shopware 6.7 auf eine neuere Vue-I18n-Version umgestellt hat. Sie werden unter 6.6 wie 6.7 wieder angezeigt.
# 1.6.2
- Fehler « Class "Alma\API\Client" not found » behoben.
- Das Alma-SDK wird mit dem Plugin ausgeliefert, aber Shopware lädt den `vendor/`-Autoloader einer aus dem Store installierten Erweiterung nie: Es registriert nur den Namespace des Plugins. Das Plugin lädt ihn nun beim Start selbst.
- Andernfalls trat der Fehler bei der ersten Verwendung des SDK auf — typischerweise beim Verbindungstest direkt nach Eingabe des API-Schlüssels — und machte das Plugin unbrauchbar. Betraf Shopware 6.6 und 6.7 gleichermaßen.
# 1.6.1
- Fehlende Administration unter Shopware 6.7 behoben.
- Das Plugin lieferte nur das alte Format der Administrations-Assets aus. Shopware 6.7 löst diese Assets jedoch ausschließlich über Vite-Einstiegspunkte auf, sodass das gesamte Administrations-Bundle des Plugins fehlte (API-Schlüsselverwaltung, Schlüsselauswahl, Konfiguration der Zahlungspläne, Erstattungskarte).
- Schwerwiegendste Folge: Das Auswahlfeld für den API-Schlüssel zeigte gar kein Bedienelement an, und das Speichern der Konfigurationsseite löschte den ausgewählten Schlüssel, wodurch Alma im Shop deaktiviert wurde. Das Plugin liefert nun beide Formate aus und funktioniert sowohl unter 6.6 als auch unter 6.7.
# 1.6.0
- Behebung eines 500-Fehlers beim Aktivieren des Plugins unter Shopware 6.6.
- Der Filter der Alma-Zahlungsarten rief `str_starts_with()` auf dem technischen Namen der Zahlungsart auf, ohne den Fall `null` zu behandeln. Unter Shopware 6.6 kann die Spalte `payment_method.technical_name` null sein: erst in 6.7 wurde sie zwingend erforderlich.
- Da dieser Filter die Store-API-Route der Zahlungsarten dekoriert, läuft er bei jedem Aufruf von Warenkorb und Checkout: eine einzige Zahlungsart eines Drittanbieters ohne technischen Namen legte den gesamten Shop mit einem 500-Fehler lahm, sobald das Plugin aktiviert wurde.
- Die Händlerreferenz wird jetzt bereits bei der Erstellung der Zahlung an Alma übermittelt und nicht mehr erst nach der Bestätigung der Bestellung.
- Die Bestellnummer wird beim Erstellen der Zahlung aus dem Shopware-Nummernkreis reserviert und anschließend von der Bestellung übernommen: Auch erstellte, aber nicht abgeschlossene Zahlungen tragen ihre Referenz nun im Alma-Dashboard.
- Hinweis: Eine abgebrochene Zahlung verbraucht eine Bestellnummer, in der Nummerierung können daher Lücken entstehen.
- Zuverlässigere Händlerreferenz.
- Eine neue stündliche geplante Aufgabe wiederholt die Übertragung der Referenz, wenn sie fehlgeschlagen ist, statt sie dauerhaft verloren zu geben.
- Die tatsächlich übermittelte Referenz wird in der Datenbank gespeichert und lässt sich so im Nachhinein überprüfen.
- Shopware-6.7-Kompatibilität: zwei für den Betrieb auf 6.7 nötige Korrekturen (keine 6.6-Regression).
- Plugin-Installation/-Update: `Connection::PARAM_STR_ARRAY` (in Doctrine DBAL 4 / Shopware 6.7 entfernt) durch `ArrayParameterType::STRING` ersetzt, das mit DBAL 3 und 4 funktioniert. Ohne diese Korrektur schlug die Plugin-Installation auf einer 6.7-Instanz fehl.
- Checkout-Widget/InPage-Rendering: Das Override `payment-method.html.twig` nutzt nun den Block `component_payment_method_field` (in 6.6 und 6.7 vorhanden) statt `component_payment_fieldset_template` (in 6.6 veraltet, in 6.7 entfernt). Ohne diese Korrektur wurden weder das Raten-Widget noch der InPage-Anker auf 6.7 gerendert.
- InPage-Zahlung: Behebung eines Zahlungsfehlers bei benutzerdefinierten Themes.
- Der InPage-Anker (das Konfigurations-Div `data-alma-checkout` + das Laden des Alma-SDK) wird nun aus der Zahlungsart-Komponente (`component/payment/payment-method.html.twig`) statt aus der Bestätigungsseite (`page/checkout/confirm/index.html.twig`) gerendert.
- Zuvor entfernte ein Merchant-Theme, das den Block `page_checkout_confirm` ohne Aufruf von `parent()` überschrieb, diesen Anker: SDK und Konfiguration wurden nicht geladen, das JS-Plugin hatte kein Element zum Anbinden, das Absenden des Formulars wurde nicht abgefangen und die Bestellung wurde ohne Alma-Zahlung aufgegeben („Missing Alma payment ID“-Fehler).
- Der Anker wird genau einmal gerendert (bei der ersten berechtigten Alma-Zahlungsart), wodurch der InPage-Ablauf unabhängig vom Layout des Themes wird.
- IPN-Webhook: Korrektur der Callback-URL bei Multi-Domain-Shops mit Sprach-Pfadpräfix.
- Die an Alma gesendete IPN-URL (`ipn_callback_url`) wird nun ausschließlich aus dem Ursprung der Verkaufskanal-Domain gebildet (`scheme://host[:port]`), ohne Sprach-/Pfadpräfix (z. B. `/et`, `/ch`).
- Zuvor wurde bei einer Domain wie `https://beispiel.com/et` die generierte URL `https://beispiel.com/et/api/alma/webhook` vom Storefront-RequestTransformer abgefangen und außerhalb des `api`-Scopes aufgelöst, was einen HTTP-500-Fehler verursachte; der Webhook erreichte den Controller nie.
- Abgleich: Die Shopware-Bestellnummer wird nun an Alma übermittelt.
- Bei der Zahlungsfinalisierung (`pay()`) wird die Bestellnummer über `order.merchant_reference` an die Alma-Zahlung angehängt, sodass die Bestellung im Alma-Dashboard auffindbar ist.
- Best-Effort-Vorgang: Ein Fehler unterbricht die Zahlung nie (nur eine Warnmeldung im Log).
- Zahlungs-Flow: Die Locale wird nicht mehr an Alma gesendet.
- Das Feld `locale` (`fr`) wurde aus dem an die Alma-API gesendeten Payment-Creation-Payload (`payments.create`) entfernt.
- Das InPage-Payment-Iframe erzwingt keine Locale mehr (`Alma.InPage.initialize`); das Feld `locale` der Storefront-Konfiguration wurde entfernt.
- Folge: Alma richtet sich jetzt nach der Browsersprache des Kunden (inklusive Fehlermeldungen), statt Französisch zu erzwingen.
- Die Anzeige-Widgets (Raten-Badges auf Produkt- / Warenkorbseiten) bleiben in der Sprache der Händler-Website lokalisiert.
- Tests: Migration der Suites `AlmaPaymentHandlerTest` und `OrderAmountFeeExclusionTest` auf die `AbstractPaymentHandler`-API von Shopware 6.6 (sie zielten noch auf die alte 6.5-API). Vollständige Backend-Suite grün (255 Tests, 0 Fehler; zuvor 27 vorbestehende Fehler).
- Shopware-6.7-Kompatibilität ergänzt (das Plugin hatte das Store-Review für 6.6 bereits bestanden):
- Composer-Constraints für `shopware/core` und `shopware/storefront` auf `~6.6.0 || ~6.7.0` erweitert.
- End-to-End-Validierung via `shopware-cli extension validate --check-against highest --store-compliance --full` gegen Shopware 6.7.10.2 (neueste 6.7): 0 Fehler.
- Bestätigt, dass die Migrationen aus 1.1.0 (`AbstractPaymentHandler`, `technicalName` an jeder Zahlungsart, Vue-3-strict-Bindings, Attribut-basiertes Routing) und 1.1.2 (Entfernung von `Context::createDefaultContext()` / `SystemSource`, Symfony HTTP Client im Provisionsbericht) bereits alles abdecken, was 6.7 erzwingt.
- Bestätigt, dass der Konstruktor des `ScheduledTaskHandler` bereits einen Non-Null-Logger an den Parent weiterreicht — entspricht der neuen 6.7-Anforderung.
- Restliche `eslint(@typescript-eslint/no-unused-vars)`-Warnungen in `catch`-Blöcken und einer Testdatei bereinigt.
- Stylelint-Validierung der Drittanbieter-CSS des Alma-SDK unter `scss/vendor/_alma-widgets.scss` deaktiviert (keine inhaltliche Änderung am Vendor-Styling).
- Anpassung an das automatisierte Review-Feedback des Shopware Store (Runde #8):
- `!important`-Deklarationen aus dem Administration-SCSS-Override entfernt (die Spezifität wird jetzt durch eine doppelte aussagekräftige Klasse getragen).
- Zwei `console.error`-Aufrufe auf der API-Key-Detailseite entfernt; nur noch der Toast-Notification-Flow als Fehler-Surface.
- Den cURL-Aufruf des täglichen Provisionsberichts auf den Symfony HTTP Client (`http_client`) umgestellt — saubere Behandlung von Transportfehlern und Testbarkeit.
- Inline-`style=`-Attribute aus den Storefront-Twig-Templates (Footer-Banner, PDP-Widget, Checkout-Datencontainer) entfernt und das Styling in dedizierte SCSS-Klassen (`.alma-plugin-info`, `.alma-checkout-data`) verschoben.
- `parent()`-Aufrufe in allen überschriebenen Twig-Blöcken des Checkout-Summary-Total-Templates ergänzt, sodass die Alma-Gebührenzeile additiv über dem Core-Layout bleibt.
- Keine `new Context(new SystemSource())`-Instanziierungen mehr außerhalb von CLI / Scheduled-Task-Code: `ConfigService::getApiKey()` erhält jetzt einen `Context` vom Aufrufer, durchgereicht über `AlmaClient` und jede öffentliche Methode, die einen API-Client benötigt (`getClient`, `getMerchantId`, `fetchPayment`, `partialRefund`, `fullRefund`); der IPN-Webhook-Controller erhält den `Context` vom `ApiRequestContextResolver` von Shopware.
- Der Scheduled-Task-Handler des täglichen Provisionsberichts verwendet jetzt `Context::createCLIContext()` (das dokumentierte Pattern für CLI / Scheduled Tasks).
- Fix für den Crash der Konfigurationsseite, wenn kein API-Key ausgewählt ist (`sw-entity-multi-id-select` erhält keinen Null-Wert mehr).
- Fix der Vue-3-strict-Event-Propagation bei Plan-Auswahl und Beträgen: API-Key-Dropdown und Min-/Max-Beträge pro Plan werden jetzt beim Speichern korrekt persistiert.
- Fix der Autorisierung des Alma-Fee-Plans-Admin-Endpoints, sodass die Konfigurationsseite die verfügbaren Pläne ohne 401-Retry lädt.
- Fix der Storefront-Eligibility-Widgets: Die Meldung „Click to find out more" und der gesamte Widget-Bereich öffnen jetzt das Alma-Detail-Modal als Vollbild-Overlay (das Alma-SDK-CSS fehlte im Storefront-Bundle).
# 1.0.3
- Plugin-Namespace von AlmaShopwarePayment in SASALMA umbenannt, um dem technischen Namen im Shopware Store zu entsprechen.
- Lizenz von MIT auf proprietär geändert, um der Konfiguration im Shopware-Konto zu entsprechen.
Shopware 
Shopware