🕵️‍♂️ Plugin Environment Scout (PES)

Plugin Environment Scout (PES) is an enterprise-grade, highly optimized, production-safe passive monitoring tool designed for WordPress core architectures. Operating entirely behind the scenes, it acts as an isolated runtime monitor to map out exactly which active plugins execute or load across WordPress's 6 isolated environments: Admin, Front, AJAX, REST, Cron, and CLI.

The ultimate objective of this utility is to generate precise architectural maps required for building ultra-fast Micro-Kernel Routing structures and selective plugin loading mechanisms [1].

---

🎯 The Core Problem (Monolithic Overloading)

By default, WordPress handles requests monolithically, loading all active plugins into memory for every lifecycle execution [1]. A plugin designed strictly for backend administration is needlessly booted up during frontend REST API or AJAX queries, draining critical server resources (RAM/CPU) and expanding the attack surface [1].

While selective plugin loading tools solve this, they present a dangerous catch-22: How do you accurately map out exactly which runtimes a plugin demands? Guessing causes catastrophic Fatal Errors. PES eliminates this risk by passively observing production traffic frequencies to compile factual routing bounds.

---

🧠 Dual-Engine Tracking Framework

Instead of speculative evaluation, PES extracts runtime logs under real production loads utilizing two parallel analysis systems:

1. Hook-based Analysis (Execution Profiling): Interrogates the global $wp_filter stack deeply at the tail-end of execution. By employing PHP Reflection, it resolves the absolute provenance of every executed callback—including closures, anonymous functions, traits, and inherited methods—back to its originating plugin directory. This is the gold standard for verifying if code actually executed.
2. File-based Analysis (Inclusion Profiling): Audits the get_included_files() internal registry at the absolute end of the request lifecycle. This tracks which plugins physically load files into runtime memory, ensuring that plugins running detached from standard hooks (e.g., independent class wrappers or bootloaders) are safely identified.

---

✨ Technical Highlights in Version 2.7.0

• 🛡️ Smart Self-Exclusion (Zero Noise Data): Dynamically detects its own operational environment. Whether deployed as a standalone single file in the root of mu-plugins/ or enclosed in an isolated directory, it purges its own execution footprints from reflection logs, maintaining 100% data purity for your micro-kernel metrics.
• 🗄️ Autoload Decoupling (autoload = false): Gathered data is committed to the options table explicitly with the autoload argument set to false. This keeps the telemetry data fully lazy-loaded, ensuring it is never pulled into frontend alloptions payload queues and saving valuable memory on high-traffic sites [5].
• 🚦 Self-Throttling DB Footprint (Max 10 Rule): To guarantee zero database or distributed cache overhead under millions of hits, tracking for each environment strictly caps at 10 counts per environment.
• 🚫 Aggressive Skip-Trace Filters: Automatically drops tracking for static assets (.js, .css, images, fonts), 404 errors, browser pre-fetches, plugin activation screens, and heavy or destructive WP-CLI operations (like core, plugin, or database updates) to preserve data integrity.

---

📊 Mathematical DB Footprint Formula

One of the key engineering achievements of PES is its absolute, finite limit on database write operations. The maximum number of times update_option() can ever be executed throughout the plugin's entire lifetime (until a manual reset) is calculated using the following formula:

$$\text{Max Write Queries} = P \times 6 \times 10$$

Where $P$ represents the number of active plugins on the site.

• Real-World Example: On a large-scale enterprise site with 50 active plugins, the system will perform a maximum of 3,000 write operations across its entire lifecycle.
• High-Traffic Performance: Once these initial hits are saturated (typically within the first few minutes of deployment), the database transaction trigger locks permanently to false. From that microsecond onward, even under 100M+ concurrent visits, the write overhead and cache invalidations in Redis/Memcached drop to absolute zero.

---

📦 Installation & Setup

For maximum architectural accuracy (capturing the earliest core boot hooks), deploying this utility as a Must-Use Plugin is highly recommended [2]. However, it is architected with dual-compatibility and can also run perfectly as a standard plugin.

Option A: Must-Use Deployment (Recommended for Enterprise)

1. Save the plugin source file precisely as plugin-environment-scout.php.
2. Upload it directly into your wp-content/mu-plugins/ directory (create the directory if it does not exist) [2].
3. The plugin activates implicitly [2].

Option B: Standard Plugin Deployment

1. Create a folder named plugin-environment-scout inside your wp-content/plugins/ directory.
2. Save the plugin source file as plugin-environment-scout.php inside that folder.
3. Go to WordPress Admin > Plugins > Installed Plugins and click Activate. Note: In standard mode, some ultra-early core execution hooks that trigger before the plugins load phase may not be profiled.

---

⚙️ Advanced Configuration (Performance Tuning)

For large-scale, high-traffic production environments, you can throttle the analysis frequency to mitigate CPU usage. Open the PHP file and locate the SAMPLING_RATE constant:

private const SAMPLING_RATE = 100;

• 100 (Default / Recommended for Testing): Profiles 100% of incoming requests. Ideal for staging or initial setup to gather immediate environment routing data.
• 20: Shuffles and samples only 20% of randomly chosen frontend requests [4]. Highly recommended for high-volume production sites to guarantee absolutely zero noticeable footprint while still compiling a robust environment dataset over time [4].

---

🖥️ Metrics Dashboard & System Scoring

The administrative control panel introduces modern indicators alongside an advanced scoring threshold:

Status Badges

• 🟩 Dark Green ($10 / 10$): Target environment tracking is fully saturated. The plugin is heavily and unquestionable bound to this runtime layer.
• 🟦 Blue ($3 \le Count < 10$): The plugin has cleared the Confidence Threshold. It is considered active and must be kept loaded in this environment.
• 🟨 Yellow ($1 \le Count < 3$): Low or volatile activity. Below the trust threshold; needs more tracking time or manual verification.
• ⬜ Grey ($0 / 10$): Zero registered activity. The plugin is a safe candidate for exclusion in this specific environment.

📋 Modern Clipboard Copy & Micro-Kernel Config Formatting

Clicking the Copy button alongside any plugin executes an asynchronous Clipboard API call, copying the raw config string optimized directly for your micro-kernel routing files, fully purged of dead parameters.

If a plugin clears the minimum configuration threshold (3 hits), the specific environment is dynamically appended; otherwise, a safe default fallback of all is declared to avoid breaking the runtime.

Sample copied output:

Scope: cli, admin, rest

This formatted header is ready to be directly mapped into your edge router or boot-level filter arrays.

---

⚠️ State Mutations (Danger Zone)

The footer features explicit action buttons secured tightly using cryptographic anti-CSRF nonces and administrative privilege validation:

• Reset Tab Data: Erases the data model strictly for the selected analysis tab engine.
• Reset All Data: Wipes the entire database footprint across both tracking engines—highly recommended when introducing structural plugin shifts or theme updates requiring fresh profiling.

---

❓ FAQ

Does running this in Production degrade site speed? No. Thanks to the strict should_skip logic dismissing static/management hits, the autoload = false flag, the database throttle capturing a maximum of 10 hits, and the adjustable SAMPLING_RATE (e.g., set to 10% or 20%), the plugin runs entirely in volatile RAM memory with zero overhead once thresholds saturate [4, 5].

Hook-based vs File-based: Which matters more? Hook-based tells you where code runs, while File-based tells you where code sits in memory. For defining micro-kernel scopes, always treat the Hook-based matrix as your primary source of truth.

---

👨‍💻 Developer & Brand

• WandTech by Hamxa Boustani (wandtech.ir)
• Runtime Layer Version: 2.7.0