magicoders

Alright, will follow up in this direction.

Hi there, thanks for the help. I’ll answer everything below:

This plugin was updated last week, do you know if that’s when the issue started?
No, I know that this is NOT when the issue started.
The issue started exactly on the 1st of July, with the last successful payment processing on June 30th.
The plugin is currently in its latest version too, by the way.

Do you have any other payment method active?
Yes, we have Stripe through the WooCommerce Stripe Payment Gateway plugin (not WooPayments) and we also have Amazon Pay.

If so, are subscriptions paid with them working correctly?
Yes, both of the other payment methods are working correctly, and the only payments failing, all with this “Authorization Failed, please verify the user for the API credentials” error, are PayPal’s.

Have you checked if everything is okay with the API keys??
Yes, we have checked. Additionally, as mentioned above, this plugin has been installed and working for years and this issue started happening all of a sudden, with the same setup that had always worked before.

Can you please share a screenshot of the order notes on one of those?
All look like this: https://snipboard.io/3LJgFS.jpg

Infos requested:

System report
https://gist.github.com/tmargulis/34410cc87983c36db677a3d025ef2af2

PayPal Braintree Log with an example sequence (they are all the same) and some redacted info to protect our customers
https://gist.github.com/tmargulis/83fc00e06480850a12c14eb22b86f219

No Fatal Errors Log

Looking forward to hearing from you

This was not actually resolved, we just decided to go with another option. Thank you for checking into this though.

Hi! Nop! Not a multisite, just a regular single WP install.

Hi Serge,

No errors in logs that I find relevant.

I don’t think CleanTalk is working on this site either, as SPAM is coming through, and it is not getting recorded in Stats in WordPress counter nor in the Cloud Dashboard. The trial is coming to an end soon, and because the service isn’t protecting the site, the client will not want to purchase the license….

Thank you,

Sure! Thanks for the incredibly speedy reply.

Awesome! Thank you so much, really appreciate it from this end as well ??

Still mind blown, several months and projects later.

Really excellent work, Tom.

OK, I see.

Is there any other way of modifying this submission form or is it just non-customizable?

Hi Ashley,

It does sound like that is what happened.

The site owner who used to use Updraft has decided to not use it anymore, and we don’t use it either. There’s no need on my end for opening a support ticket.

I now know that when using Updraft, it is a hazard and I must deactivate it as soon as localhost is installed.

On your end, your plugin should probably detect a localhost site URL and automatically deactivate automatic backups from getting backed up to a 3rd party storage, with a warning that backups to external storage has been deactivated.

So anyone who does want to still have them backed up there, still can, but you prevent this type of case like the one I described, where a non-technical client restores their live site to localhost without having a clue about URLs and databases, because the plugin has decided to backup to their external storage databases from different servers.

• This reply was modified 3 years, 9 months ago by magicoders.
• This reply was modified 3 years, 9 months ago by magicoders.

@bcrodua your reply has nothing to do with the issue I am reporting.

I am telling you a client, from his Live site and server, clicked restored in his Live server with the intention of restoring his Live site with a backup of his Live database, and the plugin restored in his live server a database that had the NEW (the localhost) URLs.

If you want to do something about it and fix your plugin, good.
I thought you would want to know that this disaster scenario could happen with Updraftplus.

The client has already decided to delete Updraftplus as a result of his experience, and we don’t use it either, this was information for you.

This looks perfect. Even if that exact snippet does not work, just knowing that there is no “flush all folders for a specific cpt”, and that you recommend using Cache_Enabler::clear_cache_on_post_save( $post_id ); is the information I was after.

Thanks for the thoughtful support, it’s much appreciated.

I think you’re on the right track re: the post is being updated, maybe Cache Enabler isn’t initialized yet.

Thanks for clarifying the plugin behavior too. As far as I see, deleting all folders under listings/ should work great, to ensure deleted listings are not cached, and that updated ones get recreated on first request.

I’m using WP All Import with customizations, although I don’t think these are relevant for the cache behavior. Can share about them too though, if needed.

Thank you very much for your time and help.

Perfect! Following up there.