Troubleshooting
The common things that go wrong, what to try first, and how to find useful clues in the debug log before asking for help.
Customers say they aren’t getting emails. What do I check first?
Check these things, in order:
- Is WooCommerce sending its own emails? If you place a test order and the “order received” email doesn’t arrive either, the problem is your host’s mail setup, not this plugin. Fix that first — install an SMTP plugin (WP Mail SMTP, FluentSMTP) if you haven’t.
- Is the email type enabled? Go to WooCommerce → Settings → Emails and check that “Order updates — customer” is enabled. Each of the nine emails has its own switch.
- Did the customer turn off notifications? Customers can unsubscribe from update emails using a link in any email we sent them. Check the customer’s email preference for that order — if it shows “off”, that’s why.
- Are you using “Send in background” mode? If your host’s WordPress cron is broken, queued emails never go out. Switch Settings → Emails → Delivery mode to “Send immediately” as a test. If emails now arrive, your cron is the problem.
- Check the customer’s spam folder. Email systems can flag automated mail as spam, especially on a new domain.
The admin bar notification dot isn’t showing new updates.
The notification dot updates from a poll every 30 seconds, not in real time. So a brand-new update may not light up the dot until the next poll. Try refreshing.
If it still doesn’t show:
- Make sure you’re a member of one of the Internal team roles set under Settings → Members. Users outside those roles don’t get admin-bar notifications — they’re not on the team.
- Check whether you muted the update (the Get notifications switch on the update card). Muted updates skip both email and admin-bar entries.
- Check whether your browser is blocking the heartbeat AJAX call — some privacy plugins do this. Open the browser developer tools, look for failed requests to
admin-ajax.phpwith actionheartbeat.
The customer portal page is broken or looks wrong.
Usually a CSS or JavaScript conflict with the theme or another plugin. Try this:
- Switch to a default WordPress theme (Twenty Twenty-Five or similar). If the portal looks right with the default theme, the issue is in your theme’s CSS.
- If still broken, disable all other plugins except WooCommerce and this one. If it looks right now, re-enable plugins one at a time until you find the one that breaks the layout.
- Open the browser developer tools console while loading the page. JavaScript errors from another plugin or theme can stop our scripts from running — the error message in the console will name the file the error came from.
I see a database error in my error log.
If the error mentions one of the plugin’s tables (e.g. {prefix}order_updates_for_woo or any of the seven sibling tables), and says the table doesn’t exist, the table creation didn’t finish during plugin activation.
Fix: deactivate the plugin, then activate it again. Activation runs the database setup step every time. If the error happens during activation itself, your database user may not have CREATE TABLE permission — check with your host.
I see a white screen or a fatal PHP error.
A fatal PHP error in this plugin means there’s a bug, and we want to know about it. To find out what happened:
- Turn on debug logging. Edit
wp-config.phpand set:define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); - Repeat what caused the error.
- Open
wp-content/debug.log— the most recent error at the bottom of the file will name the file and line.
If the error is from this plugin (the file path includes plugins/order-updates-for-woo/), please share the relevant lines from the log when you ask for help.
The analytics dashboard is loading slowly.
This is rare — the dashboard reads from a pre-built lookup table that’s kept in sync as updates change, so a store with 100k+ updates should still load in under a second.
If yours is slow:
- Try clearing the cache — Settings → Cache → Clear all cache. A stale cache key can cause repeat queries.
- Check the date range you’ve picked. A range covering several years across millions of updates will be slower than a one-month view.
- If the slowness only started after a recent update, ask your host to look at MySQL slow-query logs around that time — an index may need adding by the next plugin update.
One of my team members can’t see updates on an order.
Two things to check:
- Their role. The user needs WooCommerce’s edit shop orders capability, which by default belongs to administrator and shop_manager. Custom roles need that cap added.
- The internal team roles setting. Open Settings → Members → Internal team roles and confirm the user’s role is checked. If the role isn’t in the team list, the user can still edit orders but won’t appear in the assignee picker or get @mention emails.
How do I turn on the plugin’s debug log?
The plugin doesn’t have a separate debug log — it uses WordPress’s standard debug.log. Turn it on by editing wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
After that, any warning or error from the plugin (and from WordPress and your other plugins) will be written to wp-content/debug.log. The file may already be large — if it is, delete it (it’ll get re-created on the next error) and then repeat the action you’re troubleshooting.
After updating the plugin to a new version, a feature stopped working.
First, deactivate and reactivate the plugin. Reactivation runs the database migration step, which sometimes needs to add a new column for a new feature — if that didn’t run, the feature can’t work.
If the problem persists, check wp-content/debug.log for a fresh error from the plugin. The error will name the file and line that broke.
If you need to roll back to the previous version while you investigate, download the old version from WordPress.org → Advanced and upload it. Your data stays in place during a downgrade — the eight tables don’t get touched on plugin update or downgrade.
What should I include when opening a support ticket?
Help us help you faster by including these up front:
- WordPress, WooCommerce, and PHP versions (find these under Tools → Site Health → Info).
- The plugin version (Plugins page).
- What you did, and what you expected to happen.
- What actually happened (screenshot helps).
- The last 50 lines of
wp-content/debug.logif there’s an error in there. - Whether the problem still happens when you switch to a default theme and turn off other plugins.
Open the ticket on the plugin’s WordPress.org support forum. We read every post and respond in 1–2 business days.
I think I found a bug. Where do I report it?
The WordPress.org support forum for short reports. For deeper issues with logs, screenshots, or steps to reproduce, you can also email the plugin author directly — the contact form is linked from the plugin’s WordPress.org page.
If you’re a developer and can reproduce the bug, the most useful report includes the steps to reproduce, the relevant lines from debug.log, and (if a JavaScript bug) any console errors from the browser developer tools.