David Marín Carre?o

Acabo de a?adir una nueva funcionalidad en el plugin para permitir elegir entre a?adir el nuevo rol (comportamiento previo, y por defecto) o bien hacer que el nuevo rol sustituya al rol anterior.

Por favor, verifique si este cambio soluciona su problema.

Muchas gracias.

El desarrollo del plugin sigue activo y está funcionando a día de hoy en muchos otros sitios.

No dudo de que no funcione en su instalación. Esto puede ser por muchos y variados motivos. Desde que la pasarela de pago no haga las llamadas de hooks estándar para marcar el pago como completado (conozco el caso de una pasarela que no lo hace), o algún otro problema.

?Podría darme más información sobre su sitio, la pasarela de pago empleada, y otros plugins instalados?

• This reply was modified 9 months, 1 week ago by David Marín Carre?o.

No es lo que dicen otros muchos usuarios satisfechos…

Quizá Vd. espera que funcione de una manera diferente a como lo hace. Antes de soltar una opinión así de dura podría ponerse en contacto con el autor para averiguar qué sucede…

In order to say that your plugin is compatible with HPOS you stop considering that orders are posts, and stop messing with the post_type of the post with order_id: when syncing is disabled your plugin causes a mess in the database.

Hi!

Sorry, I’m afraid this plugin doesn’t work this way.

Marking as resolved.

Hi all!

I just generated a new version, marking it as compatible with WooCommerce HPOS (it already was compatible, but I needed to activate a flag so Woo considers it that way).

Thanks for reporting!

Basically, we have a custom plugin that makes use of this hook without providing a second argument (without $user_data), this way:

do_action( 'lostpassword_post', $errors );

This doesn’t cause any problem without WP-2FA (as all the functions in WordPress called by this hook receive one argument), but if WP-2FA is active, this call generates a fatal error due to the missing parameter.

We just propose you to simply change the line 46 of class-reset-passord.php from:

public static function lostpassword_post( $errors, $user_data ) {

to:

public static function lostpassword_post( $errors, $user_data = false ) {

Thanks for your answer.

I’m adding this try/catch block to our site, and I’ll keep working to determine why this is happening. Unfortunately, the problem doesn’t seem to be deterministic. In all our tests, and in the general case, everything works correctly. There’s something that causes this in 3 or 4 orders per week.

I’ll keep you informed if I get something clear from my tests.

We’ve seen this problem for both Credit Cards and Paypal, but in the last weeks it’s much more frequent with Paypal.

Our main concern is the fact that a problem when saving the token causes the order to be moved to failed status, even after the payment has correctly been charged. Having problems saving the token in the vault should never make the already-charged order to be moved to failed status.

Having problems retrieving the token is, at this moment, secondary for us.

Could we have an option, or even better, a filter to decide if the “Saved Account” or the “New Account” radio button is selected by default?

As I said, for us it’s really important to show the “Paypal Later” button.

Exactly.

For anonymous users, or for registered users without a Paypal payment method in their account, the Checkout page replaces WooCommerce’s default “Place Order” button with the two Paypal Buttons.

In our page, if the user already has a registered Paypal payment method associated to their account, when the saved account is selected, the Checkout page doesn’t show the typical Paypal buttons to proceed with the payment, but only the original WooCommerce’s “Place Order” button:

In this example, the selected cart doesn’t include any subscription. However, the current user has an active subscription paid through Paypal, with the saved account.

If the user selects “New Account” the two typical Paypal buttons (the standard PayPal one and the one from Paypal Later) are shown.

• This reply was modified 1 year, 9 months ago by David Marín Carre?o.

@polevaultweb I’ve been told by ACF-Pro support that you won’t support fields associated to Orders once orders in the site won’t be custom post types any longer.

I’d just like to confirm this information, in order to start moving our current Order-associated custom fields into native WooCommerce fields inside their meta-boxes, or we still should wait for a short-term incoming support: these fields currently are one of the few things that are blocking us from moving our system to HPOS.

Sorry for the misunderstanding. With “You” I meant the plugin developers ??

I’m also affected by this bug!

Yep. I’m afraid you’ve used a deprecated feature to fix the issue with the get_klaviyo_option() function…

Please, consider replacing

return $filter_var($option_value, FILTER_SANITIZE_STRING);

with the following code

$option_value = preg_replace('/\x00|<[^>]*>?/', '', $option_value);

return str_replace(["'", '"'], [''', '"'], $option_value);