WooCommerce Sales Popup Not Showing? Fix It Step by Step

Version note: product settings in this guide were checked against the TrueProof 2.4.0 release on September 17, 2026. New-install defaults and upgrade behavior are distinguished below.

Short answer: when a WooCommerce sales popup is not showing, first confirm that the widget is enabled, Real Data Mode is selected, WooCommerce is an active source, and at least one order has processing or completed status inside the selected look-back window. Then test the events endpoint, clear page and edge caches, and rule out display or JavaScript conflicts.

This guide uses TrueProof’s current settings and endpoint as a concrete example, but the diagnostic order applies to most recent-order notification plugins. Work from the data source outward: order, plugin query, REST response, page markup, browser script and visual placement. That keeps you from changing five things at once and losing the actual cause.

Fast checklist: the seven most common causes

1. The public widget is disabled. Activating a plugin is not the same as publishing its frontend output.
2. No eligible order exists. TrueProof reads WooCommerce orders with processing or completed status; pending, failed, cancelled and refunded orders are not used by the built-in source.
3. The look-back window is too short. A real order can still be excluded if it is older than the configured number of days.
4. The wrong source or mode is selected. Simulation Mode uses clearly labelled samples; Real Data Mode requires an enabled source with eligible records.
5. The current page is outside the display scope. A front-page-only setting will not appear on a product or blog page.
6. A cache still contains the old page or response. WordPress, a performance plugin, the host and a CDN can each cache a different layer.
7. The browser cannot fetch or render the event. A REST restriction, Content Security Policy, JavaScript optimizer or overlapping UI can hide a valid notification.

Find the failing layer before changing settings

Example REST payload: identity suppressed

This is a constructed format example, not a live order or customer record. The timestamp is a fixed example Unix timestamp; a real response uses its source event time.

[
  {
    "name": "Someone",
    "location": "",
    "action": "purchased Demo Mug",
    "time": 1788544800,
    "sim": false
  }
]

sim: false identifies the Real Data path; it is not a substitute for checking the source order. In Simulation Mode, keep the Demo label visible. See identity settings and upgrade behavior.

HPOS, custom statuses and JavaScript optimizers

TrueProof 2.4.0 queries WooCommerce through wc_get_orders(), rather than directly selecting orders from wp_posts. That is the relevant integration boundary to inspect for HPOS. It does not prove compatibility with every extension or custom order workflow. Record whether HPOS is enabled, your WooCommerce version, custom status and cache/optimizer versions when reporting a conflict.

The built-in status query accepts processing and completed, not arbitrary custom paid statuses. A delayed-script optimizer can separately prevent the browser request even when eligible orders exist. Keep these two diagnoses separate: first confirm the endpoint contains an event, then investigate rendering. The released event source and REST payload code are available for inspection.

1. Confirm that TrueProof is published

Open Settings → TrueProof. The setup check should show a selected source, the number of eligible real events and whether the widget is published. Under Widget status, enable notification bubbles and save. The setting is deliberately off on a new installation so sample or unreviewed customer fields are not published by accident.

Next, select Real Data if you expect actual orders. Simulation is useful for checking appearance on a new store, but its events are sample content and retain a visible Demo label. It does not prove that the WooCommerce query can find a real order.

2. Verify the WooCommerce source and order status

Under Real data sources, WooCommerce orders must be selected and WooCommerce must be active. TrueProof’s built-in WooCommerce source asks for recent orders with status wc-processing or wc-completed. This is intentional: an abandoned checkout or failed payment should not become a purchase claim.

In WooCommerce → Orders, inspect a test order that you are allowed to use. Confirm its status and creation date. If your store keeps paid virtual orders in a custom status, the default query will not treat that custom status as eligible. Do not change a real customer order merely to make a popup appear. Use a controlled test order or adapt the source in code after documenting the meaning of the custom status.

TrueProof uses the first item name for the purchase action. The order can still produce a generic “made a purchase” action if no usable item is available, but it must still meet the date and status rules.

3. Widen the look-back window temporarily

The default look-back window is 30 days. If the newest eligible order is 45 days old, the result is correctly empty. Temporarily set the window to 90 days and save. If an event appears, the problem was eligibility rather than rendering.

After diagnosing the issue, choose a window whose wording remains honest for your volume. TrueProof displays relative time, so an older event is not silently presented as if it happened today. A low-volume store can also leave the widget off until suitable activity exists. Inventing a purchase is not a valid fallback.

4. Inspect the public events endpoint

TrueProof’s frontend reads a same-site WordPress REST route:

https://your-store.example/wp-json/trueproof/v1/events

Open the equivalent URL for your store in a private browser window. A healthy Real Data response is a JSON array. Each item contains the configured public display name, optional location, action, time and a simulation flag. In fully anonymous mode the name is “Someone” and location is empty.

• An empty array ([]): the endpoint works, but no event matches the current source, status, window or licence rules.
• 404: refresh WordPress permalinks, check whether the plugin is active and verify that a security layer is not disabling REST routes.
• 401 or 403: a security plugin, web application firewall or authentication rule is blocking a route designed for public display data.
• 500: inspect the WordPress/PHP error log and reproduce with other optimizations disabled on a staging site.
• Valid events but no bubble: move to page markup, JavaScript and visual checks below.

The route is public because it returns the same fields intended for the public notification. Review those fields before publishing. If you do not want customer identity or location exposed, use the fully anonymous option.

5. Clear caches in the correct order

TrueProof caches its normalized event list for about three minutes and gives the REST response a short browser/cache lifetime. Your stack can add longer caching. After changing settings or order status:

1. Save TrueProof settings, which clears its event transient.
2. Purge the relevant page in your WordPress cache plugin.
3. Purge the exact page and REST route at the host or CDN only if those layers cache them.
4. Open a private window or hard-refresh so a service worker or browser cache is not reused.

Avoid disabling all caching permanently. The useful test is whether a fresh request sees the new configuration, not whether the site can run forever without a cache.

6. Check whether the widget is allowed on this page

Free TrueProof supports all eligible pages or the front/posts page. Pro adds selected contexts such as posts, pages, WooCommerce products and archives. If the setting is Front page only, test the WordPress front page—not a page that merely looks like the homepage in a builder preview.

View page source and search for trueproof-root. If the root is absent, the server decided not to show the widget on that request. Recheck the enabled switch and display scope. If the root exists, continue to the browser checks.

7. Diagnose JavaScript and REST failures in the browser

Open developer tools, reload the page and use the Network panel. Filter for trueproof or events. Confirm that the plugin JavaScript loads and the REST request returns HTTP 200 with an array containing at least one event.

Then check the Console for errors. Common causes include an optimization plugin that combines or delays scripts incorrectly, a Content Security Policy that blocks same-site REST requests, invalid HTML from another component, or a global JavaScript error that stops later code. Test one suspected optimizer setting at a time on staging and exclude the TrueProof script if necessary.

The widget waits for the configured start delay before rendering, remains visible for the display duration, then waits for the configured gap. A long start delay can look like failure during a quick check. Also note that closing a TrueProof bubble suppresses it for the rest of that browser tab’s session; use a private window or clear session storage for a clean test.

8. Rule out a popup that exists but is hidden

Inspect the bottom-left and bottom-right corners after the start delay. Cookie banners, chat launchers, mobile browser controls and sticky add-to-cart bars often compete for the same space. Switch TrueProof to the opposite corner and test at narrow mobile widths.

In developer tools, inspect #trueproof-root. If a card exists but is invisible, look for inherited display:none, opacity, transforms, clipping containers or a higher z-index from another widget. Fix the conflict in the theme or component responsible instead of applying a huge global z-index that may cover consent or checkout controls.

A disciplined isolation test

If the cause is still unclear, use a staging copy and record each observation:

1. Create one authorized test order and move it through the normal paid status flow.
2. Select only WooCommerce, Real Data, a 90-day window and all pages.
3. Choose fully anonymous output so the test does not expose customer fields.
4. Confirm the setup check reports one or more eligible events.
5. Confirm the REST endpoint returns the event.
6. Test with performance and security plugins active, then disable one suspected integration at a time.
7. Restore the production display scope, look-back and cache policy after identifying the cause.

This sequence separates data eligibility from delivery and rendering. If the setup check and endpoint are empty, investigate WordPress data and settings. If the endpoint has data but the page does not, investigate placement, scripts and styles.

Frequently asked questions

Why does Simulation Mode work while Real Data Mode is empty?

Simulation Mode uses a small built-in sample set. Real Data Mode queries selected WordPress sources and applies status, date and plan rules. A working demo therefore proves that the visual component can render, not that an eligible WooCommerce order exists.

Will a pending order appear?

Not with the built-in TrueProof WooCommerce source. It uses processing and completed orders. That avoids presenting an unconfirmed or failed checkout as a purchase.

Why did the notification disappear after I closed it?

The close button stores a dismissal for the current browser session. Open a new private window or clear the site’s session storage when testing.

Should I display a real customer name while troubleshooting?

No. Use TrueProof’s fully anonymous mode while testing unless you have deliberately assessed and configured another display mode. It shows “Someone” and hides city/country while preserving the real product action and relative time.

Next step

Once the popup appears reliably, test whether it helps rather than assuming it will. Use the recent-sales popup experiment plan, review the WooCommerce notification setup guide, and check the WordPress privacy checklist. A technically working notification is only the beginning; truthful fields, unobtrusive placement and measured outcomes determine whether it belongs on the live store.