Requests Module — User Guide

1. Enable requests module

2. Enable requests logging

When this is enabled, two additional sub-options appear:

3. Disable HTTP Requests logging

4. Disable REST API Requests logging

5. Clear requests table every

Summary Cards

Breakdowns

• Requests by Status — Shows the count for each status (success, error, timeout). Click a
  status to filter the list to only that status.
• Requests by Type — Shows the count for each request context type (admin, ajax, cron, etc.).
  Click a type to filter the list.
• Top 10 Domains — The most frequently contacted domains. Click a domain to filter the list.
• Performance Trends (Last 30 Days) — A daily table showing the request count and average
  runtime per day, so you can spot spikes and trends.

Plugin Filter

• Default: “All plugins”
• Lists every plugin/theme that has triggered at least one logged request.
• Select a plugin to show only its requests.

Status Filter

• Default: All statuses
• Options: success, error, timeout
• Narrow results to only requests with the selected outcome.

Type Filter

• Default: All types
• Options: ajax, rest_api, cron, xmlrpc, wp-cli, login,
  admin, frontend, core, installing, activate,
  undetermined
• Filter by the context in which the request was made.

Date Range Filter

• Two date pickers: From and To.
• Shows only requests recorded within the specified date range.

Domain Filter

• Text input to filter by target domain (e.g., api.wordpress.org).

Runtime Range Filter

• Two numeric inputs: Min and Max runtime (in seconds).
• Useful for finding slow requests — for example, set Min to 2 to see all requests that took over
  2 seconds.

Modal Header

• Request Type — The context type (admin, cron, ajax, etc.)
• Status — Color-coded success/error/timeout badge
• Runtime — How long the request took
• Domain — The target domain

URLs

• Page URL — The WordPress page that initiated the request
• Request URL — The full target URL

Request & Response Panels

Two side-by-side panels display:

• Request — The arguments sent with the request (JSON-formatted). Sensitive data such as
  authorization headers, API keys, and passwords are automatically redacted.
• Response — The response summary including HTTP status code, headers, and a body preview
  (truncated to 512 bytes for readability).

Both panels include Copy to clipboard and Share buttons for easy data sharing.

Stack Trace

A full PHP stack trace showing the code path that triggered the request. This helps identify which plugin, theme, or
core function initiated the HTTP/REST call.

Truncate Table

Removes all records from the requests log table but keeps the table structure intact. This is useful when you want
to start fresh without losing the table schema.

Drop Table

Completely removes the requests log database table. The table will be recreated automatically when the module is
next initialized.

Items per page

Control how many request entries display per page. Enter a number and click Apply. The default is
20 items per page. This setting only affects your user account.

Column Visibility

Check or uncheck columns to show or hide them. Useful for reducing clutter — for example, hiding the Page URL and
User columns when you only care about request URLs and runtimes. Settings persist across sessions.

Automatic Data Redaction

Request arguments and responses are automatically scanned for sensitive information before being stored in the
database. The following types of data are redacted:

• Authorization headers and Bearer tokens
• Cookies and session identifiers
• Passwords, secrets, and API keys
• WordPress nonces
• Any keys matching common sensitive naming patterns

URL Sanitization

Sensitive query parameters (such as tokens, keys, and passwords) are automatically stripped from URLs before they
are logged.

Data Truncation

• Response bodies are truncated to a 512-byte preview.
• Full response data is capped at 4 KB.
• Request argument values longer than 2 KB are truncated.

This prevents excessively large API responses from bloating the database.

Access Control

• All admin pages require the manage_options capability.
• All form submissions are protected with WordPress nonce verification.
• All database queries use parameterized prepared statements.
• All user inputs are sanitized with sanitize_text_field() and wp_unslash().

No requests are being logged

Causes & Solutions:

• Check that the module is enabled: Error Logs → Settings → Request Options — ensure both
  “Enable requests module” and “Enable requests logging” are checked.
• Check that HTTP and/or REST monitoring are not individually disabled via the “Disable HTTP Requests logging”
  and “Disable REST API Requests logging” checkboxes.
• If the database table was dropped, refresh the page — it should be automatically recreated.

Only HTTP requests are logged (no REST API entries)

REST API monitoring is disabled. Go to Settings → Request Options and uncheck “Disable REST API
Requests logging”.

Only REST API requests are logged (no HTTP entries)

HTTP monitoring is disabled. Go to Settings → Request Options and uncheck “Disable HTTP Requests
logging”.

The requests table is growing too large

Solutions:

• Set a more aggressive auto-cleanup schedule (e.g., Daily or Hourly).
• Use the Truncate Table button for an immediate cleanup.
• Disable monitoring for the request type you don’t need (HTTP vs. REST).

The “Plugin Name” column shows blank entries

The module identifies the originating plugin by analyzing the PHP stack trace. If the request was initiated by
WordPress core or by code that doesn’t reside within a plugin/theme directory, the plugin name may be empty. This is
expected behaviour for core WordPress operations such as update checks.

Request arguments or responses show “[redacted]”

This is the security redaction feature working as intended. Sensitive values like authorization tokens, passwords,
and API keys are automatically replaced with [redacted] to prevent them from being stored in the
database. See the Security & Privacy section for details.

Request types explained