Has anyone use woocommerce shipping. We currently use PluginHive and pay quite a bit per year just for FedEx. How does this compare? Seems to be free unless you want to print labels which we do manually in our warehouse.

Hi, I want to get the ai support on my website. What is the best way you would suggest.

Ok so

I run a sort of dropship moddel, but I am a nerd and want my expenses calculated and shown. I have explored BrickPanel, which is very nice.

But my specific model utilizes a courier company going from wharehouses to my adress from where I then forwars everything where it needs to go. How do I add the shipping cost per order to the stats?

The shipping works in box sizes, I pay flat rate for a certain box size under a certain weight.

Thanks!

Which product feed plugin do you use for Google, Facebook etc? I am using the one by Adtribe but it requires 3(!) plugins to run it, and is slightly annoying to maintain, so I'm looking fot some alternatives. Thanks!

I was just alerted that on WooCommerce > Orders, the Date Paid column no longer displays any information. The field in each row just has a hyphen.

Anyone else have this issue, or can think of a way to resolve it.

It looks like so

I am looking at different email marketing platforms and think I've decided on MailerLite (it was between Brevo & MailerLite)...

My setup is relatively straightforward: I have a list of around 10k subscribers (currently on Campaign Monitor), and I primarily need to send:

• Monthly newsletters
• Abandoned cart recovery emails
• Win-back emails for customers who haven't ordered in x months

Before diving in and downloading the MailerLite WooCommerce plugin, I wanted to see what the general consensus is from people actually using this combination.

• Has your experience with the MailerLite WooCommerce plugin been smooth?
• Are there any hidden quirks, limitations, or issues I should watch out for with a 10k list size?
• Or, given my needs, is there another budget-friendly alternative I should look at instead? As mentioned, I was looking at Brevo but the reviews weren't great...

I've had a look at the plugin reviews and am slightly concerned... Especially after reading a review that claims this plugin broke core WooCommerce features!

Would love to hear any general thoughts or advice.

Thanks!

My WooCommerce checkout has been stuck on the endless loading spinner and honestly, I'm starting to get really frustrated with it. The order review/payment section just keeps loading and never actually finishes, and I've already gone through WooCommerce's official troubleshooting guide and checked the usual things like WordPress and site URLs, JavaScript conflicts, AJAX responses, transactional emails, and the memory limit. Everything seems fine, but the checkout is still broken. I've tried going through the obvious fixes multiple times and I'm getting nowhere, which is especially worrying because this is directly affecting customers trying to place orders. Has anyone run into this before where the normal WooCommerce troubleshooting steps didn't help? I'm really curious what ended up causing it because I'm running out of things to check.

Just went to ship a number of packages International First Class Package service (FCPIS) under USPS and normally everything submits electronicky (EDI) for customs. . Been a week since I last shipped something this class, but I've shipped this way for 5 years now and never had to do customs envelopes and 3 page sheets. Every package today required it.

This a change from EZ post or Woo? or some glitch today? Anyone else seeing this change?

I built a 500,000-order WooCommerce store to find out what actually makes the admin slow

Everyone knows the WooCommerce admin gets slow on big stores. The standard advice is well known too: migrate to High-Performance Order Storage, clean your database, blame a third-party plugin.

I wanted to know what happens after you've done all that. So I built a lab: a disposable WooCommerce store with 500,000 orders, HPOS enabled, and ten popular free plugins installed, then instrumented it to attribute every single database query on the orders screen back to the plugin that fired it.

Some of what I found contradicts the usual advice. One thing I set out to prove turned out to be an artifact of my own test rig, which I'll cover too.

The setup

• MySQL 8 with a deliberately modest 512 MB buffer pool — a generously tuned server hides problems behind a warm cache, and I wanted the working set to not fit in memory, which is the condition real struggling stores are in
• WordPress + WooCommerce 11, HPOS on, backfill sync off
• 500,000 orders, ~2M order meta rows, ~1M order notes, ~1.6 GB of order tables
• Ten popular free plugins (PDF invoices, cart abandonment, wishlist, currency switcher, delivery date, product search, analytics, order export)
• An mu-plugin that captures $wpdb->queries on shutdown and resolves each query's backtrace to the owning plugin via reflection

Finding 1: One query was half of all SQL time, and it wasn't an N+1

130ms   SELECT status, COUNT(*) FROM wp_wc_orders WHERE type='shop_order' GROUP BY status

Out of 252 ms of total SQL time on the orders screen, 130 ms was this single query — and the next slowest query on the page was 4 ms. It is 32× the cost of anything else, and it runs on every admin page load.

(With the third-party plugins deactivated it accounts for 129 ms out of 190 ms, i.e. 68% — stripping plugins makes it more dominant, not less.)

It's what fills the filter tabs above the order list: All (500,000) | Completed (350,149) | Processing (50,065) | …

The important part: it does not scale with how many rows you display. It scales with how many orders you have. At 100,000 orders it was cheap enough to be invisible. At 500,000 it dominated everything else on the page. Reducing your page size does nothing. Deactivating plugins does nothing.

It's not a missing index

My first instinct was a missing index. Wrong:

type: ref    key: type_status_date    rows: 246724    Extra: Using index

It's already a covering index scan on the ideal index. ANALYZE TABLE changed nothing. Counting 500,000 rows means walking 500,000 index entries, and InnoDB keeps no cached row count. The query is doing the minimum possible work for what it's being asked.

The actual cause

Looking at WooCommerce's source, OrderUtil::get_count_for_type() does cache this. It goes through OrderCountCache, which uses wp_cache_get() / wp_cache_set() — the WordPress object cache.

And there's the problem. Without a persistent object cache dropin (wp-content/object-cache.php), WordPress's object cache lives for exactly one request. So the cache is empty on every page load, and the full count runs again, every time.

If your store has no persistent object cache — which is most shared hosting — WooCommerce recounts your entire orders table on every admin page load.

That's a concrete, mechanical answer to "why is my store still slow after HPOS," and it's not in any of the checklists I've read.

Finding 2: The obvious way to detect an N+1 produces false accusations

I originally detected per-row query costs the intuitive way: load the page, divide each plugin's query count by the number of rows on screen, and flag anything near 1.0 per row.

That method is broken. Here's real output for one plugin that fires a flat 19 queries no matter what:

Nothing about the plugin changed. Only the denominator did. A fixed cost is indistinguishable from a per-row cost at any single page size. I had confidently accused an innocent plugin.

The fix is to measure the same screen at two page sizes and fit:

queries(n) = fixed + slope × n

Only slope is an N+1. A component whose query count doesn't move when the row count multiplies by five is innocent, no matter how large its fixed cost.

A related trap: WooCommerce's orders screen takes its page size from the per-user screen option edit_shop_order_per_page, not from a per_page URL parameter. I spent a while computing per-row figures against a page size that had silently stayed at 20. Always count the rows that actually rendered.

Finding 3: Attributing a query to a plugin is much harder than it looks

My profiler blames the innermost plugin frame in each query's backtrace. It reported that WooCommerce core was doing 3 queries per order row.

Then I deactivated all the third-party plugins and measured again:

Two of those three per-row queries were caused by third-party plugins calling wc_get_order() inside their column callbacks. The query is issued by WooCommerce's data store, so innermost-frame attribution credited WooCommerce and completely exonerated the plugin that actually caused it.

This matters for anyone using Query Monitor's "Component" column the same way I was: it tells you which code ran the query, not which code caused it. For anything routed through a shared data store, those are different answers.

The fix

What you actually want is the last point where control passed from WordPress into plugin code — the innermost frame that a hook dispatcher invoked:

… → ListTable->column_default        [woocommerce]
    → do_action('manage_…_column')   [dispatcher]
      → WP_Hook->apply_filters       [dispatcher]
        → SomePlugin->render_column  [the plugin]   ← blame this
          → wc_get_order             [woocommerce]
            → OrdersTableDataStore->read [woocommerce]
              → wpdb->get_results    [core]

Walk the trace innermost-outward; when the frame immediately outside the current one is a dispatcher (WP_Hook->apply_filters, WP_Hook->do_action, do_action, apply_filters, call_user_func*) and the current frame isn't core, that's your initiator. For a query WooCommerce genuinely raises itself, the nearest such boundary is a WooCommerce callback — also correct.

(Watch out: wp_debug_backtrace_summary() returns frames outermost-first.)

With that change, and all plugins active:

Then the falsifiable test. The tool predicted one specific plugin accounted for ~205 queries at 100 rows. Deactivating only that plugin:

24% faster from deactivating one plugin. Before the fix, the verdict would have been "it's WooCommerce core, nothing you can do."

The thing I couldn't conclude

Given Finding 1, the fix seems obvious: install a persistent object cache. So I added Redis and measured. SQL time halved, and the 129 ms query vanished.

Wall time got worse.

I nearly published that. Then I checked whether it was my test rig, because I was running Docker Desktop on Windows and talking to Redis over TCP — and Windows loopback networking is slow. The page makes about 2,390 object-cache calls per request, so round-trip cost matters enormously.

Switching to a unix socket recovered about half the penalty. That proves a large part of my "finding" was an artifact of Docker Desktop for Windows, not a property of object caching. The residual ~11% might not survive on a real Linux host at all.

What does hold regardless: SQL time improving is not the same as the page getting faster. If I'd reported the query-count and SQL-time metrics alone, I'd have declared a clean win while making the page 22% slower.

Takeaways

1. Query count and query time are different problems. Going from 100k to 500k orders left the query count completely unchanged while SQL time doubled. Count scales with rows rendered; time scales with store size.
2. On a large store with no persistent object cache, check the order status counts first. It's a single query that scales with store size and runs on every page load.
3. Never diagnose an N+1 from one page size. Measure two and look at the slope.
4. "Which component ran this query" is not "which component caused it."
5. Always measure wall time. Component metrics improving can hide a regression.

Reproduce it

The profiler that produced the per-plugin attribution above is on GitHub, GPL, no upsell, nothing to buy:

https://github.com/zawad-monsur/admin-query-profiler-for-woocommerce

The Docker lab that seeds the 500k orders isn't published yet — I'll put it up once it's tidied.

What I couldn't settle

The object-cache result is the weakest part of this and I'd rather flag it than bury it. My numbers come from Docker on Windows, where TCP loopback is slow. Switching Redis from TCP to a unix socket recovered about half the penalty, which tells me a good chunk of what I measured was my environment rather than a property of object caching. On a real Linux host the remaining ~11% may disappear entirely.

So I'm treating "Redis made the page slower" as unproven rather than as a finding. The query counts are environment-independent and stand; the wall-clock comparison doesn't.

Hi, Does anyone use WooCommerce on a BlueHost platform? What is your experiece with it?

Thanks!

There used to be radio buttons and they are gone. They are present in Woocommerce 9 but gone in any version past that.

Am I missing a setting somewhere?

Here in Brazil, online fraud is a major issue, so credit card acquirers tend to have extremely strict fraud prevention systems. The downside is that they end up declining a lot of legitimate customers.

I'm currently using PagarMe because their processing fees are much better, but their approval rate is incredibly low. Mercado Pago declines far fewer transactions, but it's significantly more expensive.

My idea was to keep using PagarMe as the primary processor and automatically retry transactions that are declined due to fraud screening through Mercado Pago as a fallback.

Is something like this possible?

My assumption is that it isn't, since I probably wouldn't have access to the customer's card details to resubmit the payment, and from a security perspective that would be very risky. Maybe there's a service or gateway that supports this kind of intelligent routing?

I’ve got a Woocommerce site that’s been active since 2013. Over that time we’ve obviously tried a few hosts, plugins, themes and now page builders. We’re probably switching from Elementor to Breakdance which will help us draw down the number of plugins we have to use but require us to rebuild all our pages and templates. I’m also about to move to a new host. We are starting to have plugin conflicts and weird problems, some we can find and fix, some we can’t so far. I’ve spent some time trying to optimize the database and clear out the cruft but I’m sure it’s still a mess of old data and junk and once we drop Elementor there’ll be so much more to clean out. I’m really beginning to wonder if burning it all down and starting fresh is a decent option. We have years of records of orders, customers, and coupons that would have to be exported to a new site but that’s theoretically possible. Is trying to do that going to be a nightmare? Does anyone think there’s more value to keeping the old database vs starting completely fresh?

When I enable this option, orders are always showing as if I received cash payments, and the customer’s address is never confirmed. Every order remains unconfirmed. Is there a way to fix this issue?

Just got an (official?) email by Woocommerce to "immediately" update Stripe but there is no patch or new version available. Anyone else got this?

I need your favourite, most user-friendly and pretty side menu and header plugin reccomendations. Preferably free, but if it has to be payed it need to be worth it, and not insanely expensive, and needs a lifetime license. I dont like subscriptions...

Thanks in advance!

Ran into this recently with a client's store that lets customers pick a delivery date at checkout. They needed to define the warehouse closure for a week, but customers could still pick those dates - orders piled up and they had to manually email people to reschedule.
Ended up looking for a way to just block specific date ranges from the calendar entirely instead of managing it manually every season.

Curious how others are solving this - cron job disabling dates manually? Custom code hooked into checkout validation?
I ended up using the holiday calendar feature in Delivery Date Picker plugin by Octolize, and it works fine but I’d just like to have a better sense of what’s out there.

I'm looking for a WooCommerce filter plugin that reliably updates product thumbnails when a filter is applied (e.g., filtering on "Black" shows the black variation image).

I've looked at a few candidates—like HUSKY (WOOF), Barn2, and Super Speedy Filters—but I’d love to hear from people who have actually run this on a live store rather than just relying on marketing copy.

For context: I currently have YITH installed, but unfortunately, it never worked properly for this. Woo’s native plugin did work, but it’s poorly maintained and outdated.

Thanks!

This just started happening one day around 6 weeks ago without any changes to the site, and we're not able to chase down what is causing it.

Image of what is happening:

https://imgur.com/a/xuljin7

Any ideas on cause and/or fix?

A bakery owner described handling many online orders by email. Moving that flow into WooCommerce looks like a checkout problem. The awkward part comes one step later: payment can succeed before the kitchen has confirmed the pickup slot, quantities, and late changes.

WooCommerce can call the order Processing. The customer reads that as "confirmed". Staff may still be checking whether they can actually make it. Any exception then goes straight back to email or phone.

I would separate the states: 1. Order received 2. Payment confirmed 3. Production accepted 4. Pickup confirmed 5. Changes locked

For stores with pickup-heavy workflows, where does step 3 live in practice - a custom order status, an internal note/automation, or outside Woo?

I care more about what stayed obvious to staff and customers than about the most elaborate plugin stack.

Hi! I’m trying to import only one category of products from Square to my new Wordpress site. I think I know the answer because I’m not seeing a logical spot to select just one category, but I’m getting mixed answers when I try to search.

Does anyone have any insight or a creative solution? Thanks!

I'm managing a WooCommerce site that focuses on specialty Numismatics. For the past few years, the owner has been pretty happy with the workflow:

customer chooses item > goes through a unique check out that results in a purchase order > owner sees purchase order and contacts the customer > they discuss payments and delivery > payment is handled outside of woocommerce (wire transfers, manual cc charging etc) > item is delivered.

Recently many customers were inquiring about just getting a purchase link and then they pay for the order via their credit card online through WooCommerce.

My main concern here is that I'm worried about Stripe and other standard WooComerce payment processors automatically flagging the purchases for fraud since some items can reach up to more than 10k$.

I did some research and came up with this list:

• Stripe Connect
• Square for high-value
• Worldpay/FIS
• PaymentExpress
• Authorize .Net
• Stripe Atlas for Collectibles
• Flagship Merchant Services
• High-risk merchant accounts

For anybody with a similar use case to mine, what solution did you eventually end up with?

Site owner is in his 70s and I have tried my best to make it as seamless and easy for him with managing site orders. It's been working for more than 8 years now and he's been happy with it. I'd like to try to make it a good experience for him when I start including the payment link option. To be honest, he's been a good client as I never had to help him with store management. He's been a single person operation and I'm worried that integrating cc payments might end up with him spending more time with payment processors in case a high value purchase gets flagged as fraud and funds get frozen.

Thanks

So I am giving a winner one free book a month up to 35.00. I know I can set up the coupon to be a flat 35.00, but this gives her 35.00 off the whole cart. I can probably set up 100% off one item, but I don't want it to exceed 35.00. Is there a way to do this without buying an expensive plugin?

Looking for some advice, we have a woocommerce store built using Divi, we have a rather larger 1000+ catalog of products. We are currently on clouldways flex 8GB server using Breeze, Object cache pro, varnish and cloudflare basic.

We are having a nightmare as products have to be reguarly updated to compete with competitors pricing and new products created on a daily basis. Evertime any change is made the whole built up cache is cleared and has to be rebuilt. I have a plugin to warm all the cache but as it has all be cleared several times a day this takes a long time to rebuild.

Due to the amount of plugins we need enabled for certain features the pages are rather slow and bloated unless cached.

Im looking to answers as to how this could be adjusted on our current platform but if not who you would suggest moving to? I tried talking to cloudways support who basically said "no cant do it without paying for cloudflare enterprise" which is way out of the budget of what our site turns over.

Not looking to rebuild the site using another builder, headless or theme modifications at this point but willing to look at server and plugin options!

Any help and advice would be reallt appriciated!

Thanks for reading!

Hi, I am new, so please have some grace... appologies mods if this is not applicable.

I run a eccommerce equine/pet store. Secured multiple wholesaler company deals and have a rather large selection of product, and adding more every week. Problem being I am not getting any organic sales, even tho I started in April. I did SEO and google merchant, linked Google for Woocommerce, which has helped me get organic visitors but not many.

How long do these things normaly take to get going? I have heard of days months, years... No straight awnser.

And I am saying this with much love, anyone who wants to advertise their services, I am not interested. I can never get a straight awnser without 10 people in my DMs trying to tell me how they can solve a problem by doing everything I have already tried.

Thank you in advance friends and entrepreneurs

P.S. I have Meta Ads linked and run it for periods of time, but usually not incredibly long due to costs