Compatibility

What WordPress version do I need?

WordPress 6.2 or newer. The plugin uses a few REST API features that arrived in 6.2, so older versions will run into errors. Most live sites are on 6.4+ anyway, so this is rarely a problem in practice. If your site is still on something older, update WordPress first.

What WooCommerce version do I need?

WooCommerce 8.0 or newer. The plugin hooks into WooCommerce’s order edit screen, email system, and order panels, and the APIs used here became stable in WC 8.0. If you’re running an older WooCommerce, please update before you install — that’s safer than us shipping fallbacks for code paths that change every release.

What PHP version do I need?

PHP 8.1 or newer. The plugin uses features that arrived in PHP 8.0 (readonly properties, named arguments, constructor promotion) and a few things from 8.1 (enums, never return type). Most reputable hosts are on PHP 8.2+ today, so this is usually not something you need to worry about.

If you’re on PHP 7.x, please ask your host to update. PHP 7 stopped getting security fixes in November 2022.

Does the plugin support HPOS (High-Performance Order Storage)?

Yes — fully. The plugin uses WooCommerce’s order helpers (wc_get_order, $order->get_meta, etc.) everywhere it touches an order, so it works the same whether your store uses the new wc_orders table layout or the older posts-and-postmeta layout.

You don’t need to do anything special to turn this on. The plugin declares HPOS support in its header, so WooCommerce won’t warn you about an incompatible plugin, and there’s no separate “HPOS mode” setting inside the plugin. Switching your store from posts mode to HPOS mode keeps every update intact.

Does it work on a WordPress multisite network?

Yes. Each site in the network has its own copy of the eight database tables, its own settings, and its own update threads — there’s no shared state between sites on the network. Activate the plugin per-site, or network-activate it from the network admin if every site should have it on. Either way works.

Customer accounts that span multiple sites (via WordPress’s built-in multisite user table) work as you’d expect — a customer who is logged into Site A can only see updates on orders placed on Site A.

Does it work with page builders like Elementor, Divi, or Gutenberg?

Yes. The customer portal can be embedded inside any page built with a builder, using either the [order_updates_for_woo] shortcode or the matching Gutenberg block. Both render the same customer portal you see on the default My Account page, with all the same features — threads, replies, ratings, attachments — working inside the builder’s layout.

See User Guide → Embed in page builders for the usage examples, including how to pass the order id when the page isn’t already scoped to one customer’s order.

Will caching plugins (WP Rocket, W3 Total Cache, LiteSpeed) cause problems?

The admin side of the plugin is never cached — logged-in admins always get a fresh page from WordPress, so caching plugins are not a concern there.

On the customer side, the customer portal page renders inside My Account, which most caching plugins already skip because it’s a logged-in page with per-user content. If you’re embedding the portal on a public page using the shortcode or block, add that page to your caching plugin’s “Do not cache” list. A cached portal would show one customer’s thread to a different customer — not good.

The plugin’s own internal cache (set with wp_cache_set) is per-request and stops at the end of the request, so it never interacts with your page cache.

Will it work with my SMTP plugin (WP Mail SMTP, FluentSMTP, Post SMTP)?

Yes. Every email the plugin sends goes through wp_mail() — the same function WordPress uses for password resets and WooCommerce uses for order receipts. SMTP plugins replace wp_mail() with their own delivery, so they will deliver our emails the same way they deliver every other email on your site.

If WooCommerce’s own emails are delivering fine through your SMTP plugin, ours will too. No special setup needed.

Will it work with translation plugins (Polylang, WPML, TranslatePress)?

The plugin’s own text is translatable through the standard WordPress .pot file, which we ship in languages/. So Polylang, WPML, and other plugins that work with .pot files can pick it up and let you provide your own translations.

For per-language emails (English email to English-speaking customers, French email to French-speaking customers), the plugin reads the customer’s preferred language from WPML / Polylang user-meta when it builds the email, so the right language fires automatically — the same way WooCommerce’s own emails switch language.

Will it work with my custom theme?

Yes. The customer portal renders into the standard WooCommerce My Account page, so it picks up whatever your theme does with that page. The admin-side update card lives on the WooCommerce order edit screen, which themes never style. So the only place a theme can affect anything is the customer-facing portal — and that piece is built using the same CSS classes the rest of WooCommerce uses, so most themes already style it correctly.

If your theme styles the portal in a way you don’t like, you can override the template files (copy them from plugins/order-updates-for-woo/Templates/ into your-theme/woocommerce/order-updates-for-woo/). See Developer Guide → Theme overrides.

Can I use this alongside another help-desk plugin (Zendesk for WooCommerce, FluentSupport, AwesomeSupport)?

Yes, technically — the plugins don’t share data, so there’s no conflict. You’d just end up with two separate threads on the same order, which is confusing for your team. Pick one and stick with it.

The reason to use this plugin instead of a separate help-desk: the threads here are tied to the order they belong to, so when your team opens an order they see the support history in the same view as the order itself. With a separate help-desk app, you have to switch tools to read the conversation. Smaller stores often find that single-tool workflow much faster.

What hosting works best?

Any host that runs WordPress and WooCommerce works. The plugin doesn’t need anything special — no extra PHP extensions, no Redis, no special cron setup.

If you’re using the “Send in background” email delivery mode (under Settings → Emails), your host needs working WordPress cron. Most hosts do; cheap shared hosting sometimes doesn’t. If you’re unsure, use the “Automatic” delivery mode — the plugin will detect a working cron and use it, or fall back to immediate sending if it can’t.

Does it work on WordPress.com (the hosted service)?

Only on the Business plan or higher, which is the level where WordPress.com lets you install custom plugins. On lower plans, you can’t install third-party plugins at all, so this one won’t work there.

For self-hosted WordPress (most stores), no restriction — install and run as normal.

Does the plugin slow down my site?

The plugin only runs its database queries on pages that need them — the order edit screen, the customer portal page, the admin bar, and the REST endpoints. Pages that have nothing to do with updates (front page, product pages, checkout) don’t trigger any extra queries.

For pages that do touch the plugin, the queries go through a small per-request cache, so multiple calls inside one request only hit the database once. The analytics dashboard uses a separate, pre-built table that’s kept in sync as updates change, so even a store with hundreds of thousands of updates can load the dashboard in milliseconds.