IRL - Rules Woo Wholesale Lead Capture Plugin

[noelsaw1]

🔍 Analysis Verification

Issue 1: includes/class-wwlc-user-account.php:49 - DB Query in Constructor

Your analysis is: ✅ PARTIALLY ACCURATE

What the code does:

// Line 49 in constructor
$this->total_unmoderated_users = $this->get_total_unmoderated_users();

// Lines 1080-1090
public function get_total_unmoderated_users() {
    return count(
        get_users(
            array(
                'fields' => array( 'ID' ),
                'role'   => WWLC_UNMODERATED_ROLE,
            )
        )
    );
}

Execution path:

1. Plugin bootstrap runs on after_setup_theme hook (very early - runs on every page load)
2. WooCommerce_Wholesale_Lead_Capture::instance() is called (line 48 in bootstrap)
3. Main plugin constructor runs → instantiates WWLC_User_Account::instance() (line 93)
4. WWLC_User_Account constructor runs → calls get_total_unmoderated_users() → DB QUERY

Severity Assessment:

Factor	Value
Runs on every page load?	✅ Yes (frontend + backend)
Query type	get_users() with role filter
Cached?	❌ No explicit caching
Bounded?	⚠️ No LIMIT (could return all unmoderated users)

Verdict: TRUE PERFORMANCE ISSUE ⚠️

The get_users() call happens on every page load. While WordPress internally optimizes get_users() somewhat, this is:

1. Running on frontend pages where the count is never displayed
2. Unbounded - could be slow if there are many unmoderated users
3. The value total_unmoderated_users is only used for admin menu bubble notification

Recommended fix:

// Lazy-load: Only query when actually needed
public function get_total_unmoderated_users() {
    if ( ! is_admin() ) {
        return 0; // Don't query on frontend
    }
    // ... existing query
}

---

Issue 2: includes/class-wwlc-shortcode.php lines 376 and 402 - Direct SQL Queries

Your analysis is: ⚠️ MOSTLY INACCURATE

What the code does:

// Lines 369-385 (wwlc_registration_form_loaded)
// Lines 395-411 (wwlc_login_form_loaded)
public function wwlc_registration_form_loaded() {
    if ( is_plugin_active( 'page-builder-add/page-builder-add.php' ) ) {
        global $wpdb;
        $ulpb_front_page_id = $wpdb->get_row( "SELECT pm.post_id FROM..." );
        // ...
    }
}

When are these methods called?

Looking at lines 120 and 189, these methods are called from:

// Line 120 - inside wwlc_login_form shortcode
if ( $this->wwlc_login_form_loaded() && ! is_product() ) { return; }

// Line 189 - inside wwlc_registration_form shortcode  
if ( $this->wwlc_registration_form_loaded() && ! is_product() ) { return; }

Key findings:

1. These are NOT called on every page load
2. They are only called when the shortcode is rendered ([wwlc_login_form] or [wwlc_registration_form])
3. The SQL query only runs if Landing Page Builder plugin is active (is_plugin_active() check)

Severity Assessment:

Factor	Value
Runs on every page load?	❌ No - only on pages with WWLC shortcodes
Guard present?	✅ Yes - is_plugin_active() check
Query type	Direct $wpdb->get_row() - not using $wpdb->prepare()
SQL Injection risk?	✅ No - no user input in query

Verdict: NOT A MAJOR PERFORMANCE ISSUE ✅

However, there are minor issues:

1. DRY violation - Same SQL query duplicated in two methods (lines 376 and 402)
2. Missing prepare() - While safe (no user input), best practice is to use $wpdb->prepare()
3. Could be cached - The result could be cached with transients

---

📊 Summary

Issue	Claimed	Actual	Severity
class-wwlc-user-account.php:49	DB query every page load	✅ TRUE	HIGH - runs on every page (frontend + backend)
class-wwlc-shortcode.php:376,402	SQL every page load	❌ FALSE	LOW - only runs when shortcode is rendered AND only if Landing Page Builder plugin is active

The first issue is a real performance concern that should be fixed. The second issue is not as described - those queries are guarded by both shortcode rendering context AND plugin activation check.

Would you like me to add these findings to a project document or create detection patterns for these issues?

[noelsaw1]

📋 Plan: New Scanner Patterns for Constructor & Shortcode Performance Issues

Based on the analysis, here are two potential scanner enhancements:

---

Pattern 1: DB Queries in Constructors (HIGH VALUE ✅)

Problem detected: get_users(), get_posts(), $wpdb->query() etc. called inside __construct() methods run on every instantiation, often on every page load.

Implementation approach:

1. Add new pattern to PATTERN-LIBRARY.json
2. Detect: function __construct followed by DB query functions within ~50 lines
3. Target functions: get_users, get_posts, WP_Query, $wpdb->get_, $wpdb->query

Grep pattern (conceptual):

# Find constructors with DB calls
grep -Pzo "function __construct.*?\{[^}]{0,2000}(get_users|get_posts|WP_Query|\\\$wpdb->)" 

Severity: HIGH - These run on plugin load, affecting every page

---

Pattern 2: Unbounded get_users() Without Caching (MEDIUM VALUE)

Problem detected: get_users() without number limit or transient caching

Already partially covered: The scanner has get_users without number limit check, but doesn't detect when it's in a constructor context (which amplifies the issue).

Enhancement: Add constructor context as a severity multiplier

---

Recommended Next Step

Option A: Add "DB query in constructor" as a new pattern in PATTERN-LIBRARY.json

• Estimated: ~20 lines of pattern config + ~30 lines of detection logic

Option B: Enhance existing get_users without number limit to flag constructor context

• Estimated: ~15 lines of modification

Which approach would you prefer, or should I skip this and focus on something else?