Stef

Hey thanks @olliejones I believe we spoke on Reddit already. I forgot to update this post. We ruled you out already and notified Woo of the bug we found. Thanks.

Hey @ericnewman I found the issue myself. It’s in the free version too by the way, not their Pro version.

The issue is caused by a mismatch between the notification ID and the dismiss ID in the plugin code.

The notice is registered with:
wppb_international_telephone_input_notification_pb

But the dismiss link uses:
wppb_international_telephone_input_notification

Because of this mismatch, the dismiss action fires, but it never actually marks the correct notification as dismissed, so the notice keeps reappearing after reload.

Fix is simply to make both IDs match. For example:

$notification_id = 'wppb_international_telephone_input_notification_pb';
$dismiss_notification_id = $notification_id;

Once those are aligned, the dismissal works as expected.

I’m not sure if you know how to run CLI and work that way. That’s how I work, but here’s the patch.
Do these in this order.

cp wp-content/plugins/profile-builder/admin/admin-functions.php wp-content/plugins/profile-builder/admin/admin-functions.php.bak

perl -0pi -e "s/\\\$dismiss_notification_id = 'wppb_international_telephone_input_notification';\\n    \\\$notification_id = 'wppb_international_telephone_input_notification_pb';/\\\$notification_id = 'wppb_international_telephone_input_notification_pb';\\n    \\\$dismiss_notification_id = \\\$notification_id;/" wp-content/plugins/profile-builder/admin/admin-functions.php

sed -n '744,752p' wp-content/plugins/profile-builder/admin/admin-functions.php

Refresh the admin. Bing, bang, boom done. Took 24 seconds. Enjoy.

• This reply was modified 3 months ago by Stef.

I know, my OCD is off the charts @ericnewman I read on someone else’s post they’re on it, they should however pushed a minor patch for it instead of making everyone wait.

@crmperkshelp Thank you.

Hey @inpsydekrystian thanks for getting back to me. No worries on the timeframe. We ended up implementing the new captcha feature and so far it’s been working and the client is super, super happy. Thanks.

• This reply was modified 5 months ago by Stef.

Hi @inpsydekrystian

Thanks for the follow-up.

I don’t have a 100% reproducible sequence yet, but here’s what I can share from the live environment where it occurred:

• Environment:
  • PHP 8.2.28
  • WooCommerce with HPOS enabled
  • WooCommerce PayPal Payments 3.3.0 (now rolled back to 3.2.0)
  • Redis object cache enabled
• Features in use: PayPal smart/express buttons, Venmo, and Pay Later (no classic PayPal gateway checkout and no Advanced Card payments).
• Symptom:
  • Fatal error in the logs: PHP Fatal error: Uncaught Error: Call to a member function id() on null in wp-content/plugins/woocommerce-paypal-payments/modules/ppcp-wc-gateway/src/Gateway/PayPalGateway.php:592
  • Shows up as intermittent 500 errors on the frontend during checkout.
  • Not every transaction triggers it.

After rolling back from 3.3.0 to 3.2.0, the PayPalGateway.php:592 fatal stopped appearing in the logs and we haven’t seen the 500s since, which suggests something introduced in 3.3.0 is occasionally causing wc_get_order() to return null in that code path.

I can’t trigger it on demand yet, but I’m happy to enable any additional debug logging you recommend around the wc_get_order() call and the gateway logic, then temporarily switch back to 3.3.0 during a low-traffic window on live to capture more detailed context for you.

Let me know what extra logging or constants you’d like me to enable and I’ll try to get you better data. I can even write a custom script if need be.