Advanced

Debugging with Verbose Logging

Published · Last updated

The plugin can record the moments where it decides not to do something. This is gated behind a constant and is off by default. Use it to diagnose, then turn it off.

What it traces

Verbose logging is not a general request log, and it does not record prices, visitors or requests. It records the handful of defensive paths where the plugin backs out rather than risk breaking the page:

  • A theme or plugin throwing an error or a fatal while the plugin renders the alternative Add to Cart state for a product, naming the state it was rendering.
  • An Add to Cart region on a single product page that left the output buffer unbalanced, so the region was not tagged.
  • A stock-asset primer failing for one of the two stock states.

Each of those is a silent no-op by design — the plugin would rather leave a working page alone than tag something it could not render cleanly. The trade is that when a region is not being refreshed, there is nothing on the page to say why. That is what this log is for.

Note

If prices or stock are not updating at all, this is not the tool to reach for first. Start with Troubleshooting and the browser console – a JavaScript error or a cached endpoint accounts for most cases, and neither writes anything here.

Enabling it

1. Enable the plugin constant (e.g. in wp-config.php, above the “stop editing” line):

define( 'SSAP_VERBOSE_LOGGING', true );

2. Read the log. Entries go to the WooCommerce logger under the source super-speedy-ajax-prices, so the easiest place to read them is WooCommerce → Status → Logs, picking that source from the dropdown.

Where the WooCommerce logger is unavailable, the plugin falls back to error_log() with a [Super Speedy AJAX Prices] prefix. To capture that, switch on WordPress debug logging:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // don't show errors on the page
tail -f wp-content/debug.log | grep 'Super Speedy AJAX Prices'

Reading the trace

Entries are single lines naming what failed and what the plugin did about it, for example:

counterfactual loop button threw: Call to a member function get_id() on null
single add-to-cart region: unbalanced output buffer, not tagging
asset primer threw for outofstock: ...

The message text after the colon comes from whatever threw, so it usually names the theme or plugin at fault directly. A counterfactual loop button line means that product’s Add to Cart button will not be swapped when its stock state changes; an unbalanced output buffer line means that product page’s Add to Cart area is left untouched.

An empty log is the normal state. Nothing here fires on a healthy page.

Turning it off

// remove, or set to false
define( 'SSAP_VERBOSE_LOGGING', false );

…and disable WP_DEBUG_LOG again if you only turned it on for this. There is no privacy clean-up to do afterwards – the log records error text and stock states, not visitors – but it does write on every affected render, so leaving it on a busy site costs disk for no benefit.

Further reading

start here when prices or stock are not updating.
the plugins and themes already known to throw in these paths.
the constant itself, and the endpoint contract.

Comments

▲
▼
1/1