spottedpaint
Forum Replies Created
-
Ok, thanks it looks like it isn’t compatible then, unless anybody else has experience of using the two plugins alongside each other.
- This reply was modified 10 months, 3 weeks ago by spottedpaint.
Forum: Plugins
In reply to: [Clearpay Gateway for WooCommerce] Undefined $locale variable Version 3.8.1Yes it has in my local test environment with this new version 3.8.2.
Forum: Plugins
In reply to: [Clearpay Gateway for WooCommerce] Undefined $locale variable Version 3.8.1I’ll mark it resolved.
Forum: Plugins
In reply to: [Clearpay Gateway for WooCommerce] Undefined $locale variable Version 3.8.1Thank you
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] PAYER_ACTION_REQUIRED is not a valid statusThanks Joost, sorry I missed your initial reply. We do have a lot of pre orders where people pay a deposit. I’ll try and have a look and see if I can tell if this is more likely to occur when they are just paying a deposit.
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Error after update last versionI’m having a similar issue when I have the woocommerce-deposits plugin active. It didn’t happen on version 2.0.1
Notice: Function get_cart was called <strong>incorrectly</strong>. Get basket should not be called before the wp_loaded action.
….
wp-includes/functions.php on line 5835
Do you want me to raise a new ticket or provide more details?
Yes only on the note that the merchant sees. It would give the merchant some more information when examining their orders.
These orders havn’t been failing for us, its only a desire to make the message clearer.
I’ll have check on the next ones to come in to see if that 150% amount would apply to them. Perhaps the same 150% issue might also apply if they added an additional item to their basket after they had been to PayPal and authorised an amount.
The guys at inpsyde spotted I had multiple webhooks setup, apparently more webhooks isn’t better. I removed the second webhook around lunchtime yesterday and since then the number of failed orders seems to have reduced. I’ll keep monitoring it but I didn’t have any failed orders last night.
I thought it might tie in with Paypal doing some maintenance but the only thing could see that they admitted too was some planned maintenance on the night of the 5th. Thats not actually listed on their website anymore https://www.paypal-status.com/history/production . We are in the UK. We had suffered some other issues with being unable to make a refund payment via the paypal site recently. When paypal have had issues in the past things tend to start working again later and they don’t tend to admit to anything.
Hi Niklas,
I’ve sent you a system report and some logs, with some examples.
It seems in consistent, some customer attempt fail then the next order will be them succeeding. I’ve not included those ones in the examples.I’ve not managed to reproduce the failures. It seems inconsistent because all around them there are successful payments. Some people failed a few times in a row. There have been have been 20 failed orders since the 3rd of August so it seems high. 23 altoegther in August.
There were 62 in July
39 in June
25 in May for comparison. So it seems to be an increasing issue.It would be neat to work out some kind of explanation. I can’t really switch to just storefront because its a live site.
WP Super Caching is set to off in the plugin settings.Yes 2.1.1 pity I can’t change it in the original comment.
Sorry the latest version 2.1.2
Forum: Plugins
In reply to: [WPS Hide Login] Undefined index: path (version 1.9.1)The main thing was to tell you about it. As long as your aware its up to you if you want to change your code or not.
The mirasvit url is just an example to make it easier to reproduce.
Forum: Plugins
In reply to: [WPS Hide Login] PHP Debug logI have the same problem, I found it was caused for me by urls with double slashes like https://example.com//admin or https://example.com//monkey.
In those circumstances parse_url doesn’t gets confused and doesn’t populate the path key so it produces
array(1) { ["host"]=> string(6) "monkey" }
rather than
array(1) { ["path"]=> string(7) "/monkey" }
like you might expect.I’ve put an extra line in wps-hide-login/classes/plugin.php just under $request = parse_url( $_SERVER[‘REQUEST_URI’] ); in the function plugins_loaded().
To make sure the path key is always populated.
$request = parse_url( $_SERVER['REQUEST_URI'] ); if(!isset($request['path'])){ $request['path'] = ''; }
parse_url also occurs in other places in that class but they don’t seem to error, I think because in my instance at least those urls get redirected to
https://example.com/admin or https://example.com/monkey