# SofortPay - Release Log There were several issues detected and debugged with some customers that lead to the release of two new plugin releases. ## Version 2.0.9 PHP-Requirements: **PHP<=7.3.x** Shopware-Requirements: **5.2.13 - 5.6.10** (5.6.99 defined as theoretical max version in the *plugin.xml* file) Download via Google Drive: https://drive.google.com/file/d/1qwaDyitkg04E8CgwSiSdjCvgtrdZANfI/view?usp=sharing  ### Explanation of changes: - If a guest order chooses to cancel the SofortPay transaction (or if an error occurs), the plugin previously redirected to the **/account/payment** controller which is only accessible for registered customers. The plugin now redirects to **/checkout/shippingPayment** which is accessible for both customer modes (The hint for this misbehavior was discussed and detected by ***https://heilkundeinstitut.at/***) - If the shop is configured to **not** set customer numbers (*Basic settings* > *Login / registration* > ***Generate customer numbers automatically***), the session / customer check on each SofortPayment action *failed since it expected an existing customer number* and redirected to the login page. This is now changed to identify the customer by his **ID** in the database. (The hint for this misbehavior was discussed and detected together with ***http://shop.ahw-shop.de***) ### Written changelog (can be used for the store upload) #### DE: - Weiterleitung für Kunden ohne Kundennummer (Konfiguration "Shopware generiert Kundennummern" = `nein`) korrigiert - Fix für Redirect von Gastkonten auf /checkout/shippingPayment nach Zahlungsabbruch #### EN: - Redirect of customers without customernumber (Configuration "Generate customer numbers automatically" = `no`) correctly - Fixed redirect of guest accounts to /checkout/shippingPayment after payment cancellation ## Version 3.0.0 PHP-Requirements: **PHP>=7.4.x** Shopware-Requirements: **5.7.0 - 5.7.2** (5.7.99 defined as theoretical max version in the *plugin.xml* file) Download via Google Drive: https://drive.google.com/file/d/10Uz1QwtbtO8mqP8NATSMMcaCfY4RnnKM/view?usp=sharing  ### Explanation of changes: - The PHP minimum version was raised to 7.4 for Shopware 5.7 - This implies that functions need proper type declarations. The SofortLogger component now needs a parameter type declaration since the dependent library changed the base method that is overridden by SofortPay - Some services need to be made public to be used by the SofortPay controller without dependency injection - Due to the change of type declarations the plugin in version 3.0.0 is no more compatible with Shopware versions <5.7 / <PHP 7.4 ### Written changelog (can be used for the store upload) #### DE: - Plugin-Kompatibilität für Shopware 5.7 hinzugefügt, PHP 7.4 type declarations aktualisiert #### EN: - Added plugin compatibility for Shopware 5.7, updated PHP 7.4 type declarations ## Version 3.0.1 (Backwards compatibility added) (16.07.2021) PHP-Requirements: **PHP<=7.3.x** - **PHP>=7.4** (backwards) Shopware Requirements: **5.2.13** **Background**: Even though the two releases 2.0.9 and 3.0.0 should ease the transition from Shopware <=5.6 to Shopware 5.7 it may be possible that the Shop crashes during or after the Shopware update because the type declaration of the function *addRecord* of **SofortLogger** is recognised as faulty as soon as the services in Shopware 5.7 are compiled. With version 2.0.9 installed before the Shopware update, the update client should notify the customer that the version is **not** compatible with Shopware 5.7 and therefore should be deactivated. Unfortunately this step can be skipped and then leads to the crash. After that the plugin can only be deactivated via direct database access (Set the plugin to `active = 0` in `s_core_plugins`). After a discussion with **fabian@meisinger.software** (Klarna customer) it would significantly reduce the frustration during updates if that type declaration issue is bypassed entirely. Download via Google Drive: https://drive.google.com/file/d/1c8WsfAPbTHF7d2Db1p4fBJRw4rO3cQED/view?usp=sharing  ### Explanation of changes: - Before the services / PHP classes are loaded, there is a Shopware version check that decides wether to load the Shopware 5.7 version of the **SofortLogger** class *OR* a duplicate class **SofortLoggerLegacy** which is simply the file version prior to the 3.0.0 update. - Tested steps: - Install Shopware 5.6.10 with the 3.0.1 version => plugin works - Raise PHP Version to 7.4 for the Update to Shopware 5.7 - Run Shopware Update 5.7 - On the switch between Shopware 5.6 to 5.7 the container switches to the respectively correct versions of the **SofortLogger** class and does not crash anymore - Customers on Shopware Versions <5.7 can update to plugin version 3.0.1 and can update to 5.7 now or later without facing fatal errors or the *"deactivate" - "update Shopware" - "update to plugin 3.0.0" - "re-activate plugin"* steps ### Written changelog (can be used for the store upload) #### DE: - Abwärts-Kompatibilität für Shopware Versionen unter 5.7 wieder hinzugefügt #### EN: - Re-added backwards compatibility for Shopware versions less than 5.7 ## Version 3.0.2 (Payment Token name changed) (01.09.2021) **Background**: A request made by a Klarna customer said that user sessions sporadically get lost after purchase => after the Shopware update from 5.5.10 to 5.6.10. The only relevant change for the Plugin is the mechanism of Session restoration. Download via Google Drive: https://drive.google.com/file/d/1zUAFNbs64rGh6mFFhTeMdAyMFh6rRnn6/view?usp=sharing ### Explanation of changes: - When redirected to the Klarna Payment page, a token is generated to restore the user session once the payment has succeeded and the user got redirected to Shopware - The transmitted parameter for this token was named **token**. At the time this functionality was implemented, there was no own Shopware mechanism released yet to restore the user session. - With Shopware 5.6 this mechanism was made compatible with the payment process but the parameter name given by Shopware was **swPaymentToken** - As of Shopware 5.6 the generated token was named **swPaymentToken** but the check in the Plugin still refered to **token** - In this scenario no token can be received to restore a user session - **NOTE** this is only reproducable if a payment action exceeds the session lifetime. - By renaming the used parameter within SofortPay to **swPaymentToken**, this possible issue is resolved ### Written changelog (can be used for the store upload) #### DE: - Payment-Token Namen geändert auf swPaymentToken #### EN: - Payment token remaned to swPaymentToken ## Version 3.0.3 (Session check updated) (03.09.2021) **Background**: After change 3.0.2 the customer could still reproduce the issue. ~~Download via Google Drive: https://drive.google.com/file/d/1M3HbaOwPTX3zK5E6J-cx2QXh4YyZEiSk/view?usp=sharing~~ ~~### UPDATE (07.09.2021): Download link with annotation to pass code check: https://drive.google.com/file/d/10dkNZn0Z343N0GxJG7HdTmmesAzr8OTV/view?usp=sharing~~ ### UPDATE (08.11.2021): Refactor code to prevent parsing and code analysis errors on store upload: https://drive.google.com/file/d/1pzN641ojzZukWk6eSq1XKEIfLcuQ5I7W/view?usp=sharing ### Explanation of changes: - As of Shopware 5.6 the **PaymentTokenService** does the session restoration itself and deletes the backup data but the payment data is not directly accessible yet via Session, but a cookie. - The check in the plugin tries to get the value from the already deleted data and cannot set a cookie and won't find required data for the customer check. - For older Shopware versions this process is done by the plugin. - If the required cookie check is placed after both Shopware's own restoration and the optional restoration by the plugin, a valid value can be fetched, redirect to the account page is prevented and the order can be created correctly. ### Written changelog (can be used for the store upload) #### DE: - Session-Prüfung bei Redirect zum Shop nach Zahlung aktualisiert #### EN: - Changed session check on redirect to shop after payment