Hello @embercide
Thanks for reaching out to us, we’re here to help.
The fatal error is most likely triggered because our plugin uses a previous version of psr/log , as defined in woocommerce-paypal-payments/blob/trunk/composer.json with "psr/log": "^1.1" . The more recent version that would be compatible with PHP 8.2 is this one: https://packagist.org/packages/psr/log#3.0.0. The Psr/log version 3.0.0 requires PHP version 8.0.0 or higher and uses Union types in its arguments, which PayPal Payments doesn’t support yet.
Most likely, some other plugin on your site implements the library psr/log in version 3.0.0, which is incompatible with the version used in PayPal Payments.
The first step is to confirm which one triggers this, so you may want to perform a full conflict test. We recommend temporarily activating the default theme Storefront and disabling all other plugins except for WooCommerce and PayPal Payments, and then enabling other plugins one by one to see when the error occurs. Let us know about the outcome.
Alternatively, a potential workaround would be downgrading to PHP 7.4. For a complete fix, we are in the process of merging a crucial update that will address this compatibility issue permanently. You can follow the progress of this update through our GitHub repository:
We anticipate integrating these changes by q2 with the release of PayPal Payments version 3.0+. This update will ensure that all dependency conflicts are resolved.
Should you need any more help, feel free to reach out.
Kind Regards,
Krystian
Hi @inpsydekrystian
I note that if I downgrade to plugin 2.9.4 the site appears stable, so this would suggest changes in your plugin between 2.9.4 and 2.9.6?
I can see that psr/log 3.0.0 was released in Oct 2022, so it’s only natural that other plugin developers would be using this 2 years after it was released. It’s questionable that a plugin for a service as widely used as PayPal would be so far behind in support?
Also suggesting as a workaround to downgrade php to 7.4 when it went EOL and hasn’t received security patches since 2022 is incredibly disturbing!
Hello @embercide
The fact that changing the plugin version affects it is a bit concerning. I suggested the conflict test because I’d like to identify which plugin is triggering this. That would help us reproduce the problem and potentially create a ticket for our developers. Please let us know what you find, as we haven’t been able to replicate this at all. This is important for us to understand. We’ve had a few similar reports (around 3-4), but so far, no one has provided further details.
Regarding PHP support, we acknowledge that moving forward, modularity will address these compatibility concerns soon (after the 3.0.0 update). However, at that stage, it would introduce additional consequences, particularly for older PHP versions. This is why the transition is not an immediate or simple workaround.
Kind Regards,
Krystian
Hello @embercide
A little update from my end.
We created a fix for an upcoming major update (date TBD) using scoped psr namespaces to address the compatibility issue. In the meantime, we have prepared an alpha version using this solution which you can download from here.
We would appreciate your feedback on whether this alpha version resolves the fatal errors you’ve been encountering with the regular plugin. Thank you!
Kind regards,
Krystian
Hello @embercide
Since we have not received any further communication from you, we are assuming that your issue has been resolved.
Therefore, we mark this thread as resolved. If you still have any questions or if a new problem arises, don’t hesitate to open a new thread.
Kind regards,
Krystian
