Additional Info: There seems to be no data loss during activation of the fatchip PayOne plugin, my data loss was caused by our internal verification/integration test. Sorry for the misleading information.
Thanks, Jens-Christopher Trant [Closed]<http://www.closed.com/> Closed GmbH | Straßenbahnring 6 | 20251 Hamburg | Germany T +49 40 441840 865 | M +49 151 28439981 | E [email protected]<mailto:[email protected]> closed.com<http://closed.com> | facebook.com/closed<https://www.facebook.com/closed> <http://www.facebook.com/closed> | instagram.com/closedofficial <https://www.instagram.com/closedofficial/> Amtsgericht Hamburg HRB 53868 | Umsatzsteuer-Ident.-Nr.: DE 164980577 GF: Gordon Giers, Til Nadler, Hans Redlefsen Von: Jens Trant <[email protected]> Datum: Dienstag, 10. April 2018 um 13:22 An: "[email protected]" <[email protected]> Betreff: EE 5.3.7 migration to EE 6.0.2 is buggy Hi guys, I spent yesterday only a few hours for a test migration from EE 5.3.7 to 6.0.2, which seems to be actually buggy. Maybe there is a newer/more compatible source for migrations which I have missed?! My source was the official documentation: https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/database.html Below you can see the results of the short test migration and possible solutions for common errors in the migration process. The migration SQL script seems to have some bugs (migrate_ee_5_3_to_6_0.sql): - All shop names will be replaced, the update command for CE & PE is not modified for EE users in the EE script -> To solve this you have to remove OXNAME = 'OXID eShop 6' on line 10 - If you use MySQL >= 5.7 strict mode is by default active and NO_ZERO_DATE and NO_ZERO_IN_DATE is set in the sql_mode option by default, the migrate script will produce fatal errors by many statements. -> You can solve this by adding SET @@session.sql_mode = ''; to the beginning of the script Further if you used the Fatchip PayOne module in the CE, PE or EE before, you are not able to activate this module after migration in the backend (Error: Module could not be loaded). - This is caused by the new module path (fc/fcpayone) and the old encoded oxconfig values in the database where the path is still the old one (fcPayOne). I tried two options for trying to fix this, but both will result in loosing data (all fatchip transaction tables are empty after activation)! -> Option A: Set a symlink in the modules directory for fcPayOne -> fc/fcpayone -> Option B: Update the 'aModulesPaths' in oxconfig via SQL -> SQL: UPDATE `oxconfig` SET `OXVARVALUE` = ENCODE( REPLACE ( DECODE ( OXVARVALUE ,'YOUR_ENCODING_KEY' ) ,";s:8:\"fcpayone\";s:8:\"fcPayOne\";" ,";s:8:\"fcpayone\";s:11:\"fc/fcpayone\";" ) ,'YOUR_ENCODING_KEY' ) WHERE OXVARNAME = 'aModulePaths'; I also noticed that the GitHub page of the PayOne module (which is already bundled with Oxid v6) says: 'Please note, that this extension is not yet released in production.' (https://github.com/PAYONE-GmbH/oxid-6), obviously the description is outdated. I Hope the information will help some of you, feel free to share this in forums/social media/mails/or anything else you prefer ;) Thanks, Jens-Christopher Trant [Closed]<http://www.closed.com/> Closed GmbH | Straßenbahnring 6 | 20251 Hamburg | Germany T +49 40 441840 865 | M +49 151 28439981 | E [email protected]<mailto:[email protected]> closed.com<http://closed.com> | facebook.com/closed<https://www.facebook.com/closed> <http://www.facebook.com/closed> | instagram.com/closedofficial <https://www.instagram.com/closedofficial/> Amtsgericht Hamburg HRB 53868 | Umsatzsteuer-Ident.-Nr.: DE 164980577 GF: Gordon Giers, Til Nadler, Hans Redlefsen
