=== Site Signal – Performance Triage ===
Contributors: wpwhysoslow
Tags: database, diagnostics, performance, site health, reporting
Requires at least: 6.2
Tested up to: 7.0
Requires PHP: 7.4
Stable tag: 1.6.3
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

A read-only dashboard showing which WordPress, database, PHP, and server signals may be slowing down a site.

== Description ==

Site Signal – Performance Triage reports evidence. It does not delete, repair, optimize, or change site data.

Current checks and reporting include:

* Database and largest table sizes
* Green, yellow, and red size ratings tailored to common WordPress table types
* Plain-language table tooltips explaining likely sources of bloat
* Autoloaded options
* Stored and expired transients
* WP-Cron overdue tasks
* Action Scheduler failures and backlog
* Post revisions
* Spam and trash records
* WordPress debug log size
* Database response time
* PHP memory headroom and OPcache
* Persistent object cache detection
* Active plugin surface
* In-progress background actions
* PHP worker exhaustion guidance
* Asynchronous WordPress Dashboard summary widget
* Very large database tables surfaced in the Dashboard widget
* Live CPU context where trustworthy, or Not available on hosts such as WP Engine
* A green, yellow, red, or gray expert-triage panel covering the first 10 checks professionals make
* Public versus cache-bypass browser response timing
* Database running threads, slow-query rate, and table-lock wait rate
* Page-cache, object-cache, APM, recent-code-change, and disk-space detection

Flagged signals receive a 1-10 likelihood estimate. The score reflects the strength and relevance of the evidence; it does not claim to prove causation.

404 rates and historical table growth are intentionally not estimated without a reliable evidence source.

== Installation ==

1. Upload the plugin ZIP through Plugins > Add New > Upload Plugin.
2. Activate Site Signal – Performance Triage.
3. Open Site Signal – Performance Triage in the WordPress admin menu.

== Frequently Asked Questions ==

= Does Site Signal – Performance Triage change or optimize my site? =

No. It is a read-only reporting plugin. It does not delete records, optimize tables, change configuration, deactivate plugins, or run repairs.

= Does it show exact PHP worker usage? =

Usually not. WordPress does not normally receive PHP worker-pool capacity, queue depth, or active-worker counts from the hosting platform. The plugin marks unavailable evidence gray and explains where to check it in the hosting dashboard.

= Why can the CPU number differ from my hosting dashboard? =

PHP may see a shared server, container, or quota rather than site-specific CPU usage. The CPU meter is context, not proof. On hosts where the reading is known to be misleading, it is shown as unavailable.

= What do the colors mean? =

Green is within the plugin's documented tolerance. Yellow needs attention. Red is a likely problem. Gray means WordPress cannot access enough evidence to rate the item.

= Does the plugin collect or send site data? =

No. It has no analytics, tracking, account, or external service. The full report makes two same-site homepage requests in the administrator's browser to compare normal and cache-bypass response time; it stores no request history.

== Privacy ==

Site Signal – Performance Triage does not collect personal data, set tracking cookies, contact an external service, or transmit diagnostic results. Reports are available only to administrators with the `manage_options` capability.

== Changelog ==

= 1.6.3 =
* Renamed the plugin to Site Signal – Performance Triage to meet WordPress.org naming rules and avoid a collision with an existing plugin.
* Aligned the public slug, package directory, and translation text domain as site-signal.
* Prepared dynamic database table identifiers with the WordPress 6.2 identifier placeholder.
* Added missing translator notes and removed direct stream file operations flagged by Plugin Check.
* Updated compatibility metadata for WordPress 7.0.

= 1.6.2 =
* Added gray Expert Triage states when WordPress cannot access the required evidence.
* Kept measured values within tolerance green instead of treating missing host data as a warning.
* Added green, yellow, red, and gray health highlighting to meaningful Server & Runtime rows.
* Rated free RAM, current and peak database connections, running queries, slow queries, lock waits, PHP memory limits, and request memory pressure.
* Changed unavailable CPU and RAM meters from yellow to gray.

= 0.6.1 =
* Made Expert Triage the primary diagnostic section and removed the redundant Start Here section.
* Changed the top Likely problems and Possible slowdowns totals to count red and yellow Expert Triage checks.
* Kept Other useful signals limited to revisions, spam/trash, PHP memory, and OPcache so it does not repeat Expert Triage.
* Updates the top summary after the browser response check finishes.
* Shows the top three red or yellow Expert Triage alerts in the WordPress Dashboard widget, with red ranked first.

= 0.6.0 =
* Added an Expert triage panel covering the first 10 checks a WordPress professional typically makes.
* Every expert check is labeled green, yellow, red, or gray; unavailable host evidence is gray with a specific next step.
* Added browser-based public and cache-bypass response timing without storing request history.
* Added database running threads, slow queries per hour, and table-lock waits per hour.
* Added page-cache, object-cache, Query Monitor/New Relic, recent active-code change, and disk-space checks.
* Added direct guidance for PHP workers, access logs, bots, 404s, AJAX, XML-RPC, APM, cache hit rates, and hosting error logs.

= 0.5.0 =
* Added green, yellow, and red ratings for database tables using table-type-specific thresholds.
* Added accessible explanations of common bloat causes for options, posts, metadata, Action Scheduler, WooCommerce, logs, and other tables.
* Added up to five red-rated tables to the WordPress Dashboard widget.
* Shows CPU as Not available on WP Engine instead of displaying a misleading shared-host measurement.
* Added shared-host guidance beside CPU readings.

= 0.4.3 =
* Removed one-time CPU pressure from the likelihood ratings because a page-load spike is not reliable evidence of sustained server pressure.
* Kept CPU as a live five-second context meter on both dashboards.
* Changed the initial CPU state to Measuring until the first complete average is available.

= 0.4.2 =
* Corrected inflated CPU readings by measuring the change between five-second samples instead of measuring the polling request itself.
* Uses host-wide CPU counters before container-level fallbacks for better agreement with server monitoring tools.
* Added the same live CPU and used/total RAM readings to the full plugin dashboard.

= 0.4.1 =
* Added live CPU and RAM updates to the WordPress Dashboard widget every five seconds while visible.
* Added cgroup CPU measurement with safe server-load fallbacks.
* Changed server RAM to show used and total memory, such as 1.5 GB / 8.0 GB.

= 0.4.0 =
* Added full Server, Database, and PHP runtime panels to the main report.
* Added CPU and RAM meters, database connection pressure, PHP limits, cache status, and advanced server identity.
* Expanded the dashboard widget with CPU, RAM, PHP, database, and background-work meters.

= 0.3.0 =
* Added a WordPress Dashboard widget with four performance numbers and the three most important slowdown signals.
* Loads dashboard diagnostics asynchronously so the main dashboard is not blocked by the scan.
* Sorts flagged signals by severity and likelihood score.

= 0.2.0 =
* Expanded diagnostics for PHP, database response, caching, background work, plugins, and errors.
* Added plain-language explanations and investigation guidance to every result.

= 0.1.0 =
* Initial diagnostic dashboard.
