Closed shaunek-hero closed 7 months ago
@shaunek-hero Thanks for reporting this issue! We've created a Story to fix it after replicating it on our end.
@shaunek-hero We've attempted to replicate this issue on a few clean installs, and have been unsuccessful. Upon installation of the plugin, the default value of test should be added to 'bitpay_checkout_endpoint'. Are you able to provide us with the following information so we could attempt to replicate the issue locally?
Wordpress 6.4.3 Woocommerce 8.4.0 PHP 8.2.15
If it helps I have replicated it again on a test site using a webhosting provider, Cloudways. I am highly doubtful this is Cloudways-specific, but just mentioning these EXACT steps in case you have more trouble replicating locally. Here are the steps I took:
woocommerce_bitpay_checkout_gateway_settings
I'm not sure what you are doing that is different but if there is any chance that you are reusing a database somehow, I recommend avoiding that. Use a brand new environment where you install just WP+Woo+your plugin.
Hope that helps.
@shaunek-hero I've been able to replicate this now, it looks like this issue occurs when you try to access the plugin settings before enabling the payment method itself, inside of the WooCommerce settings. Thanks for the additional information, it was really helpful!
I installed the plugin in our prod environment for the first time and immediately noticed a fatal error with the plugin when I tried to visit the settings page for the first time.
From the user's perspective the Woocommerce > Settings > Payment > BitPay Checkout for WooCommerce 5.3.2 page doesn't load the content (the Wordpress admin loads partially, just not the settings fields). Looking into chrome dev tools I could see that there was a 500 error and when I inspected the error log I see this:
As a temporary workaround I commented out lines 91 & 92 of
class-bitpaypaymentsettings.php
which is the inside part of this if-statement:Then I was able to load the settings page and save my settings. Afterwards I uncommented those lines and the page continued to work okay.
So this problem is really only for fresh installs where a user has never saved the settings for this plugin before. I checked the
master
branch and I believe this is still an issue there as well. This bug isn't urgent for me since I figured out a workaround, but I'm reporting it so that your other user's can have a better experience.