Spencer Finnell

Hello David,

_simpay_payment_confirmation ends up calling the simpay_charge_created and simpay_subscription_created legacy hooks inside the [simpay_payment_receipt] shortcode. You can use whichever fits your needs.

Thank you for bringing this to our attention David. We will look in to the posted solution and include any necessary updates in the next release of the plugin.

Hello David,

You have two options:

1. You can use the simpay_after_checkout_session_from_payment_form_request hook which runs after a Stripe Checkout Session is generated — but happens before the payment is fully completed (it may be abandoned while on the Stripe.com hosted Checkout page).

2. Ensure the page you have set in Settings > General > Payment Success page includes the [simpay_payment_receipt] shortcode. This shortcode is required to run the legacy simpay_charge_created hook.

Hello Stéphane,

Are you using any other plugins that utilize the legacy version of Stripe Checkout?

If both v2 (legacy) and v3 (recent — what WP Simple Pay uses) versions of the Stripe scripts are loaded on the same page it would cause an error like this.

If you need to exclude WP Simple Pay’s v3 script from interfering with another plugin on your website you can see how to exclude the assets from certain pages here: https://github.com/wpsimplepay/WP-Simple-Pay-Snippet-Library/blob/master/conditionally-dequeue-scripts-styles.php

Hi @vikas1010

WP Simple Pay will integrate with the required SCA payment regulations in an upcoming release by utilizing the updated Stripe Checkout payment pages.

You can read more about those here: https://stripe.com/payments/checkout

Hey @wiredmark

You can use the following to retrieve the form ID:

add_action( 'simpay_charge_created', function( $charge ) {
	global $simpay_form;

	$form_id = $simpay_form->id;

	// Use $form_id...
} );

I hope that helps!

Spencer

An update is being released shortly. Sorry for the trouble.

An update is being released shortly. Sorry for the trouble.

The last few release of Listify include many, many speed improvements. I would recommend updating as soon as possible and you shouldn’t have any more issues.

Sorry, you’re right the endpoint does return the HTML. However, this is true for all themes that use the plugin.

Can you confirm the client is running Listify 1.6.0?

I see some modifications in the returned data that Listify does not do by default. Have you tried with a clean install of the parent theme?

Again, emailing me with any more details will be much more helpful! Thanks

Correct, so

– With Listify theme: 8 seconds.
– With TwentySixteen: 0.7 seconds.

Must be loading the full listings page then, not the AJAX endpoint URL in your browser. As loading example.org/jm-ajax/get_listings/ simply returns the cached query results which Listify will not modify at that point.

If you email me with your site details I will be happy to take a closer look.

“Calling” meaning loading the URL in your browser?

Listify doesn’t modify the initial query unless you are searching with coordinates, which wouldn’t be the case on a clean load of the URL. So at that point the theme would not make a difference.

Can you please email me directly at spencer at astoundify.com with some more information? Would love to see if we can help you speed this up.

Please also ensure you are using the latest version of Listify, 1.6.0

Hey Diego!

Caching the fully formatted HTML result is definitely an option. However just wanted to point out that Listify functions the same as a default WordPress theme in this sense.

The plugin runs:

https://github.com/Automattic/WP-Job-Manager/blob/master/includes/class-wp-job-manager-ajax.php#L128

Which is looping through the (cached) results and rendering a template file for each listing found. This is the same process on all themes. Listify just does a bit more with the template file that is loaded than the default plugin.

Hope that helps!

Update your version of PHP for a quick fix. We’ll take a look for the next version.

Can you link me to your site Adam?