robertstaddon
Forum Replies Created
-
Wow, you are right. So Stripe shows in the log a 400 error to POST /v1/payment_intents
The error message is:
parameter_invalid_integer – level3[line_items][0][quantity]
Invalid integer: 1.5Can you add an option or hook to optionally disable level3 data in your plugin?
I can confirm that upgrading to Site Kit 1.107.0 resolved the issue for me. Thank you!
Forum: Plugins
In reply to: [The Events Calendar] Divi Conflict – Tag PagesWell done! I can confirm that version 6.1.4 has fixed this conflict with Divi tag templates on my site. Thank you!
Forum: Plugins
In reply to: [The Events Calendar] Divi Conflict – Tag PagesThe release of The Events Calendar 6.0.12 in April broke the functionality of any Divi Theme Builder Archive page for WordPress Tags. The archive template no longer applies and instead shows a default WordPress page. Disabling The Events Calendar solves this problem.
I have had an open ticket with The Events Calendar paid support since May 11th and they were able to replicate the issue on their side on May 23rd. The latest word that I have received on the issue was June 15th when their support rep wrote, “I can assure you that the team is actively working on resolving this issue.”
It’s now August 10th and the current version 6.1.3 of The Events Calendar still has this bug with Divi. You currently have to keep your plugin on version 6.0.11 for full compatibility with the Divi theme.
I’m going to chime in here as another WPML user who just upgraded to Site Kit 1.106.0 and started experiencing this same fatal error as everyone else. I rolled back to 1.105.0 for now.
I just installed the latest version of Code Snippets Pro (3.4.2) and this bug was fixed. Thank you!
This can actually be fixed with a simple hook into “wc_stripe_generate_create_intent_request” to switch the “lifetime” interval being passed to Stripe to an acceptable value of “sporadic”.
// Fix bug in WooCommerce Stripe payment intent request with "lifetime" not being a valid interval add_filter( 'wc_stripe_generate_create_intent_request', 'woo_lifetime_create_intent_request', 11, 3 ); function woo_lifetime_create_intent_request( $request, $order, $prepared_source ) { if ( isset( $request['payment_method_options']['card']['mandate_options']['interval'] ) ) { if ( "lifetime" === $request['payment_method_options']['card']['mandate_options']['interval'] ) { $request['payment_method_options']['card']['mandate_options']['interval'] = 'sporadic'; } } return $request; }I experienced this same issue! It appears that the Stripe plugin passes the interval of the subscription to Stripe, which doesn’t accept the “lifetime” option.
Forum: Plugins
In reply to: [Redirection] URL Monitoring auto-create two redirect recordsHopefully the developer will be able to roll out a fix for this issue in the next version of the plugin and allow users to not set an Associated Redirect value. In the meantime, there’s a simple code change in the redirection-settings.php file of the plugin that will allow you to clear this field on the settings page and avoid creating duplicate redirects every time. You can find it in this pull request: https://github.com/johngodley/redirection/pull/3585
Forum: Plugins
In reply to: [Redirection] URL Monitoring auto-create two redirect recordsThis is happening to me as well! It appears to be caused by the “Create associated redirect” setting on the “Options” page defaulting to “/”. If you were to change that setting to create an associated redirect “/amp”, then the second redirect you see would have the “/amp” at the end. The frustrating thing with the current version of the plugin is that you can’t switch this “associated redirect” off! If you delete the value in the “Create associated redirect” setting field, it defaults back to a simple “/” and creates redirects that are exact duplicates.
Thank you! I think that this would be a very helpful setting. Is there any documentation on the code and filters provided by the plugin that allows saving an ACH payment method?
Thank you for the quick reply. No, this particular product was not a subscription (I thought that I had also tested a subscription product but I guess not, I will do that). So does this plugin only save the ACH payment method into Stripe and the WooCommerce My Account area when a subscription is being purchased? If so, is there a reason for this behavior? I know that a customer has the option to choose to save a credit card for future use when purchasing a non-subscription product.
- This reply was modified 3 years, 3 months ago by robertstaddon.
- This reply was modified 3 years, 3 months ago by robertstaddon.
I left a good review and I’m happy to say that the ACH payment cleared successfully after 6 days and that WooCommerce automatically completed the order.
Unfortunately, the ACH payment method was never saved in WooCommerce in the My Account area: https://ibb.co/3zPCxBR
And, even worse, it was never saved in Stripe under the Customer account:
https://ibb.co/Tqb3fXtHello @hannahritner , thank you for the quick reply! The Email Customizer uses the a mockup order by default so this Fatal Error fires as soon as it loads. Wouldn’t it make sense to update your plugin so that it’s mockup order had enough mockup data so as to not cause a fatal error when anyone is using the official WooCommerce Shipment Tracking extension? Do you think your developers might benefit from taking a look at this?
Thank you for this quick response and helpful clarification! I am indeed seeing the payment as “Pending” in Stripe. Do you know how long it typically takes for an ACH payment to move from pending to succeeded?