Skip to content
noughtdigital
Menu
Nought SuiteWP Aware Errors

When PHP falls over.
See the WordPress around it.

A WordPress-aware exception debugger. It attributes frames and hooks, explains the request, suggests fixes, and keeps a local history of recent errors.

Why WP Aware Errors

An exception screen that knows which plugin, theme or core file actually failed.

WP Aware Errors replaces the generic exception screen with one that understands WordPress. Stack frames and hook callbacks are attributed to core, a plugin, a theme, an MU-plugin or Composer vendor code. It records sanitised hook arguments, names the REST route or AJAX action, checks plugin requirements, and adds WooCommerce context when WooCommerce is present. The same package loads as a normal plugin, a theme drop-in, or an MU-plugin.

A better starting point

On local and development sites, or when WP_DEBUG is on outside production, WP Aware Errors renders the failure itself. It refuses to render in production unless you explicitly allow it. Recent errors stay under Tools → WP Aware Errors.

  • A fatal error names a file and a line, then leaves you to guess which plugin registered the callback.
  • REST and admin-ajax failures rarely say which route or action was running.
  • Query Monitor-style context usually means another plugin, and it is not there when the request already died.
  • Production must not show a developer error screen to visitors.

In practice

From task
to done.

How the product fits into the work you already do.

Catch a local fatal

  1. Set WP_ENVIRONMENT_TYPE to local or development, or enable WP_DEBUG off production
  2. Load the package as a plugin, from the theme, or from an MU-plugin loader
  3. Trigger the error
  4. Read the owning plugin, the recent hooks and the request
  5. Open the file in your editor from the stack frame

Review what already failed

  1. Open Tools → WP Aware Errors
  2. Read the stored exceptions from this environment
  3. Copy the context if you want it in an editor or an AI session

What’s inside.

The capabilities behind the product.

01

Component ownership

Stack frames and hook callbacks are attributed to WordPress core, plugins, themes, MU-plugins or vendor code.

02

Hook argument inspection

Recent hooks keep a bounded, sanitised snapshot: type, count and keys, not a deep copy of large payloads.

03

REST and AJAX identification

The screen names the REST route, method and parameters, or the AJAX action that was running.

04

Dependency checks

Reads Requires Plugins, and checks WordPress and PHP requirements. WooCommerce extensions are checked against WC requires at least and WC tested up to.

05

WooCommerce context

When WooCommerce is present, the screen can show version, wc-ajax, HPOS, cart count and total, and the current page.

06

Suggested solutions

Built-in solution providers, plus a filter so a project can add its own.

07

Local error history

A compact history of recent errors under Tools → WP Aware Errors. It can be turned off or capped.

08

Editor links

File links open in Cursor or VS Code, and the screen can copy an AI-ready context for the error.

Fits your workflow.

01

WordPress

Plugins, themes, MU-plugins, hooks, REST and admin-ajax.

02

WooCommerce

Optional context and extension compatibility headers. The package still runs without WooCommerce.

03

Cursor and VS Code

Stack frames can open as local editor links.

Technical details

One package, three install modes

The same entry file detects a normal plugin, a theme drop-in under wp-content/themes, or an MU-plugin loader. There is no separate theme edition.

No Composer at runtime

Classes live under src/ with a small PSR-4 autoloader. WordPress does not need Composer to run it.

Production stay-off

The screen does not render in production unless WP_AWARE_ERRORS_ENABLED and WP_AWARE_ERRORS_ALLOW_PRODUCTION are both true.

Early fatals

dropins/fatal-error-handler.php can be used as wp-content/fatal-error-handler.php for failures that happen before the full package boots.

System requirements

  • WordPress 6.2 or later
  • PHP 8.0 or later

Privacy and security

The error screen can include request paths, hook names, query text when SAVEQUERIES is on, and parts of the request. Headers and known secrets are redacted. Do not enable the production override on a public site.

Your toolkit, your choice

One product.
Or the connected Suite.

Choose an individual product licence or ask about Nought Suite. Contact us for pricing and availability.

Compare product licences ↗

Questions

Is this Query Monitor?

No. Query Monitor is a broad development panel. WP Aware Errors is the screen you get when an exception or fatal happens, with WordPress ownership, hooks and a local history of those failures.

Will visitors see this on a live site?

Not by default. It renders for local and development environments, or when WP_DEBUG is on outside production. Production needs two explicit constants before it will show the screen.

Can it live in a theme instead of the plugins screen?

Yes. Require wp-aware-errors.php from the theme and it reports Theme Drop-in mode. An MU-plugin loader is detected the same way.

Does it need WooCommerce?

No. WooCommerce version, HPOS, cart and wc-ajax context appear only when WooCommerce is installed.

Can we add our own suggested fixes?

Yes. Filter wp_aware_errors_solution_providers and add a class that implements the solution provider interface.

What are we
building next?

Tell us about it