Closed rommelfreddy closed 1 month ago
Hi thx for the info, iam going to add some checks so the polyfill class is not loaded directly.
about shopware version restriction, sadly there are too many merchants which still runs shopware 6.4.x thats why we cant drop the support. i prefer to use the polyfill classes because if we drop a version at some point, i just have to delete the polyfill classes and the code stays the same.
sorry, but this will not solve the issue. still happens on the latest version.
maybe it will help to have two different release-lines.
--
i'm sorry to say that, but these polyfills are very terrible. Your fix would not solve the issue, because it still could happen, that your module got (class-)loaded before shopware - what it look likes. In this case, your check if the PaymentException-Class does exist, will always fail. --> usage of not existing AsyncPaymentFinalizeException
Hello @BlackScorp can you give me feedback on this please?
If I a cancel the payment or the payment will failure, then a fatal exception will happen within the Shopware Store.
Seems like that the Polyfill for PaymentException Class is loaded before Shopware, so the class will be Polyfill-Class will be registered before the Shopware-Class is registered.
Personal opinion of DEV: I do not think it is a good idea, to have too many polyfill for Shopware. It would be better to restrict the compatibility to the Shopware versions. I also develop a few payment provider extensions, and we decided to do not keep the compatibility to lower SW-Versions if the codebase is too different (e.g. missing exception-classes)
Much better solution: