If customer forget to fill any of required filed he will not be notfy which input he forget to fill!
Especially in the mobile, he will scroll down until the add to cart button, he will require to go up again to check what he mess to fill input.
What I recommended to do is to have a border color with red and auto-up scrolling to that input.
Is there any way I can achieve this?
Thanks for the plugin.
Sometimes AutoGPT get stucks and I have to delete the plugin and redownload it.
Is there a way to see causes of errors?
I’m using the plugin with WordPress multi.
]]>The ‘AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber’ element is invalid – The value XXXXXXXXXXXXXXXXXXX is invalid according to its datatype ‘String’ – The actual length is greater than the MaxLength value.
]]>if (!$(“#wpsl-search-input”).val()) {$(“#wpsl-search-input”).addClass(“wpsl-error”).focus();
}
As a temporary fix I have gone in and removed the .focus() within the plugin code but would prefer a permanent solution.
Thank you.
I’m needing a little help with the displaying the error message that gets sent back from stripe.
The element ID that it lands is “pmpro_message_bottom” which has an inline style display to none.
When the error msg comes back, such as “Your card number is incomplete.”, nothing changes that display to block…
How would I do this?
Thanks in advance.
]]>WP_DEBUG
set to true
), trigger_error
does not log anything in the expected location.
I see the reason is \stcr\stcr_utils::__construct()
calls set_error_handler()
to set its own error handler.
There does not seem to be any mechanism to prevent that from happening. Is there one? Also, with your overridden error handler, where do the messages actually get logged (I can’t find any log file)?
May I suggest the error handler be removed. It should not be down to individual plugins to control and change global error handling and reporting (for which there are already well-defined mechanisms via php.ini
and WP_DEBUG
-related constants – with the exception of plugins specifically for that purpose).
The error code is deprecated, although they are still allowing it.
Basically, the error code 10486 means a funding source failure from any of these reasons:
The billing address associated with the financial instrument could not be confirmed.
The transaction exceeds the card limit.
The transaction was denied by the card issuer.
The way you are SUPPOSED to handle this, is to RESTART the purchase so the buyer can choose another payment method. It may be they tried with guest checkout, it may be they got the address wrong, it may be they entered the card number incorrectly.
Rather than customers GIVING UP because they just see an error, you need to adjust this so that customers get redirected properly.
Here is the advice about this being deprecated:
https://developer.paypal.com/docs/classic/express-checkout/ht-ec-fundingfailure10486/
And here is the correct way to handle the error response:
https://developer.paypal.com/docs/archive/checkout/how-to/customize-flow/#manage-funding-source-failure
]]>Unfortunately, the EXIT() and DIE() PHP functions seem to break the page completely, as does the WP_DIE() function. I’ve been reduced to putting in a bunch of IF statements to check for previous errors and collecting error information in variables. There’s gotta be a better way, and I’m betting the users of these forums know all about it.
Can someone direct me to some explanations that make actual sense?
Thanks!
]]>I would like to report all WP errors from new created WP_Error instances to Sentry. How do this?
]]>