chenszo

No custom code needed, it’s two small things.

First, edit the paperback product, scroll to Product data and open the Inventory tab. If “Sold individually” is ticked, untick it and Update. That box is what caps it at one per order.

Second, your button sends people straight to checkout, so they never see a quantity box. You can either point the button at the product page instead (it has the quantity picker built in), or keep the straight-to-checkout link and let them change it on the cart page, so use /cart/?add-to-cart=YOURID instead of /checkout/.

If you’re on the newer block checkout, quantity can’t be edited on the checkout page itself, which is why the cart page route matters. Also double-check shipping is set per item (or by weight) so 3 books don’t ship for the price of 1.

Your hunch is probably right. Error code 1006 is a Cloudflare page, it means “your IP has been banned” by whatever site sits behind Cloudflare. Dropbox and Google Drive in the free version both do their token handoff through auth.updraftplus.com, so if that relay is blocking your OVH IP, both break on the same day exactly like you’re seeing.

Quick way to prove it: from the server (SSH or ask OVH support), run curl -I https://auth.updraftplus.com and look for a 403 with cf-ray in the headers. Send them that ray ID plus your server’s outbound IP, that’s what they need to unblock it.

While you wait, don’t sit there with no offsite copy. Amazon S3 or FTP in the free version talk to the storage directly and don’t touch the relay, so either one gets you backed up again tonight. Switch back to Dropbox once they clear the IP.

I think the delete-and-re-add is what’s biting you. Your link is checkout/?add-to-cart=1079, and that number is a product ID. When you deleted the paperback and made a new one, the new one got a new ID, but 1079 is still sitting in your Trash (I can see “Trash (1)” in your screenshot) with the old price.

Hover the new paperback in Products and you’ll see “ID: ####” under the name. Swap that number into whatever button or link points to add-to-cart=1079, then empty the trash so the old one can’t sneak back in.

If it still shows the old price after that, you’re on Bluehost, so purge their cache too (the Caching option in the admin bar) and test in a private window with an empty cart.

Good catch on the SVG. WordPress doesn’t store width/height in the metadata for SVG uploads, so when Rank Math builds the logo ImageObject for the schema there’s no height key to read and it throws that notice on every single page load. That’s how you get to 1GB.

Couple things worth doing now that it’s fixed. Empty that log (rename it or truncate it, it won’t come back on its own) so it isn’t eating your SiteGround disk quota. And for the PNG, Google wants the logo at least 112px square, so give it something around 512px and it’s happy in rich results too.

If you’d rather keep the SVG on the front end, you can still use it in the theme header and just point the Local SEO logo field at the PNG. Rank Math would probably want to hear about this one too so they can add an isset check on that line.

Since it still fails after 3+ minutes with nothing showing as in progress, the lock row is probably stuck in the database, not on disk. Back up the DB first, then in phpMyAdmin (or WP-CLI) look in wp_options for names starting with updraft_semaphore_ or updraft_last_lock_time_ or updraft_lock_ and delete just those rows. Then try one manual backup.

If they keep coming back, two things I’d look at. Your custom cron job: if it hits wp-cron.php every minute it can keep waking an old half-dead backup that grabs the lock again. Pause it while you test. And if you have Redis or Memcached object caching on, flush it, since a cached copy of that option can outlive the real one.

The fact that it clears when you toggle Rank Math is the tell. That notice isn’t a live check every page load, it gets saved into Rank Math’s own notifications when it sees blog_public as 0 at some moment. Reactivating wipes that list, so the message goes away until something trips it again.

So I’d look for what briefly reports blog_public as 0. Run wp option get blog_public right after the notice comes back. If it says 1, something is filtering it on the fly, not saving it. Search your plugin and theme for pre_option_blog_public, option_blog_public and wp_robots. A robots.txt handler that runs a check against the option, or a sitemap routine that fakes “private” for a request, can be enough.

Also worth testing with your geo plugin off for a full day, not just a toggle, since the old notice can hang around from before. If it never comes back, it’s the plugin. If it does, the Rank Math team will want to see it with Health Check troubleshooting mode on.

That DROP isn’t touching your data. wfls_role_counts is a little scratch table Wordfence’s login security rebuilds to count users per role, so it drops the old copy and makes a fresh one. The fatal means your database user isn’t allowed to run DROP (or CREATE) on that database, which some hosts lock down.

To get back in: open your host’s file manager or FTP, go to wp-content/plugins and rename the wordfence folder to wordfence-off. WordPress deactivates it and the site loads again.

Then check the DB user’s privileges. In cPanel that’s MySQL Databases, click the user next to your database and make sure ALL PRIVILEGES is ticked (CREATE, DROP and ALTER are the ones that matter here). If you can’t change it yourself, ask your host to grant those on your WP database. Rename the folder back, log in, activate again and it should build the table fine.

Worth knowing too: other plugins that run updates will hit the same wall later, so fixing the privileges now saves you a repeat of this.

Your two examples are a really clean repro. My guess is the undo for a multi-item cart goes through the ajax cart refresh, while emptying the cart reloads the whole page, so only the first path got broken in 11.2.x.

Before blaming Woo though, rule out the site. Install Health Check & Troubleshooting, turn on troubleshooting mode (it only affects you, visitors see the normal site), switch to Storefront with just WooCommerce active and run example 1 again. Keep the browser console open when you click Undo and see if a JS error shows up.

If a page cache plugin is running, double check the cart page is excluded too. A cached cart does odd stuff like this.

Still broken in troubleshooting mode? Then it’s a real regression and worth an issue on the WooCommerce GitHub with exactly what you posted here. Meanwhile WP Rollback can put you back on the last 11.1 release if undo matters for your store.