IRL - SBI MKII plugin - Patterns

[noelsaw1]

GREP-Detectable Anti-Patterns (Code Quality Scanner)

This list highlights common anti-patterns observed in this project that can be detected with simple GREP / ripgrep rules. The intent is to catch regressions early in code review or CI.

---

1) Multiple Refresh Endpoints / Overlapping Actions

Problem: Different AJAX actions for the same behavior increase brittleness and inconsistency.

GREP Patterns

• sbi_refresh_repository
• sbi_refresh_status

Interpretation

• If both appear in active code paths, you likely have redundant refresh flows.

---

2) Mixed Rendering Paths

Problem: Mixing server-rendered HTML with client-side DOM manipulation leads to duplication (e.g., duplicated buttons).

GREP Patterns

• row_html
• rows_html
• append\(html\)
• innerHTML =

Interpretation

• If you render HTML in the backend and set DOM with innerHTML/append, ensure a single owner of rendering.

---

3) Inline Script for Core Actions

Problem: Inline JS actions bypass the primary frontend controller and diverge from FSM-driven flow.

GREP Patterns

• <script> (within PHP templates)
• $(document).on\('click', '\.sbi- (inline jQuery handlers)

Interpretation

• Core action handlers should live in a dedicated JS/TS module.

---

4) Shadow State Stores / Globals

Problem: Global variables and ad-hoc flags compete with FSM state.

GREP Patterns

• window\.sbi (especially window.sbiSystemLoading, window.sbiActiveRequests)
• var .* = .*; // fallback

Interpretation

• Any fallback/global state should be explicitly quarantined or removed.

---

5) Duplicate Diagnostics Panels

Problem: Multiple debugging systems (SSE diagnostics, AJAX debug, inline logs) fragment observability.

GREP Patterns

• debug (broad scan for debugLog, sbiDebug, debug panel)
• SSE / sse in UI templates

Interpretation

• Diagnostics should be centralized and share a common schema.

---

6) Action Buttons Always Rendered Regardless of State

Problem: Always rendering generic actions (like Refresh) increases DOM churn and duplication risk.

GREP Patterns

• sbi-refresh-status
• Refresh (in action rendering code)

Interpretation

• If Refresh is always appended while other actions are conditional, consider standardizing action rendering logic.

---

7) Hidden State Transitions in Non-FSM Paths

Problem: Calling FSM transitions from many different code paths can cause races.

GREP Patterns

• refresh_state\(
• transition\(

Interpretation

• Multiple call sites should be audited and consolidated.

---

Usage Notes

• These patterns are intentionally broad. When detected, review the context before flagging as a violation.
• The ideal is to keep canonical endpoints, single renderers, and FSM-driven state changes.

---

Follow up by ChatGPT 4.1

Here’s how I would split the IRL-KISS-SBI patterns between the GREP scanner and the PHP (tokenized) scanner:

Best for GREP Scanner (simple, file/text-based, language-agnostic):
1. Multiple Refresh Endpoints / Overlapping Actions
 - Patterns: sbi_refresh_repository, sbi_refresh_status
 - Rationale: Simple string search, no context needed.

To genericize patterns like sbi_refresh_repository and sbi_refresh_status for other plugins/themes, use a regex that matches any common namespace or prefix followed by a refresh-related action. For example:

• Regex: \b([a-z0-9_]+)?refresh(repository|status)\b

This will match:

• sbi_refresh_repository
• myplugin_refresh_status
• customprefix_refresh_repository

You can further generalize by allowing for other common action suffixes (e.g., refresh_data, refresh_cache):

• Regex: \b([a-z0-9_]+)?refresh[a-z0-9_]+\b

This approach will catch refresh actions across different naming conventions, making the rule reusable for any plugin or theme.

2. Mixed Rendering Paths
 - Patterns: row_html, rows_html, append(html), innerHTML =
 - Rationale: Detectable by searching for keywords in PHP/JS.

3. Inline Script for Core Actions
 - Patterns: <script> in PHP, $(document).on('click', '.sbi-
 - Rationale: Regex/string search in templates and JS.

5. Duplicate Diagnostics Panels
 - Patterns: debug, SSE/sse
 - Rationale: Broad keyword search, best as a GREP warning.

6. Action Buttons Always Rendered Regardless of State
 - Patterns: sbi-refresh-status, Refresh
 - Rationale: Simple keyword search in rendering code.

Best for PHP (Tokenized) Scanner (needs code structure/context):
4. Shadow State Stores / Globals
 - Patterns: window.sbi*, var ... = ...; // fallback
 - Rationale: Detecting global state and fallback logic is more robust with token/context analysis, especially in JS/PHP.

7. Hidden State Transitions in Non-FSM Paths
 - Patterns: refresh_state(, transition(
 - Rationale: Requires understanding call sites, function context, and FSM structure—better suited for tokenized/static analysis.

Summary:

• Use the GREP scanner for broad, language-agnostic, or string-based patterns.
• Use the PHP/tokenized scanner for patterns that require code context, variable scope, or function/call analysis.

[noelsaw1]

You have exceeded your premium request allowance. We have automatically switched you to GPT-4.1 which is included with your plan. Enable additional paid premium requests to continue using premium models.Your proposed anti-patterns are real-world, practical, and highly relevant for modern WordPress/JS plugin development. Here’s a pragmatic evaluation for inclusion in a GREP-based pattern library:

---

Patterns Well-Suited for GREP Scanner

1. Multiple Refresh Endpoints / Overlapping Actions

• Pattern: \b([a-z0-9_]+_)?refresh_[a-z0-9_]+\b
• Rationale: This is a common source of code bloat and confusion. The generic regex is reusable and will catch most redundant AJAX/action endpoints.
• Practicality: High. Easy to implement, low false positive risk, actionable.

2. Mixed Rendering Paths

• Patterns: row_html, rows_html, append(html), innerHTML =
• Rationale: These keywords reliably flag places where rendering logic may be duplicated between server and client.
• Practicality: High. Simple string/regex search, context review needed but valuable for code health.

3. Inline Script for Core Actions

• Patterns: <script> in PHP, $(document).on('click', '.sbi-
• Rationale: Inline scripts are a maintainability/code quality smell. These patterns are easy to grep and review.
• Practicality: High. Broad but effective for flagging code that should be modularized.

5. Duplicate Diagnostics Panels

• Patterns: debug, SSE, sse
• Rationale: Centralizing diagnostics is best practice. These keywords are a good first-pass signal.
• Practicality: High. May need context review to avoid noise, but worth flagging.

6. Action Buttons Always Rendered Regardless of State

• Patterns: sbi-refresh-status, Refresh
• Rationale: Simple string search in rendering code. Helps catch UI duplication.
• Practicality: High. Low implementation cost, useful for UI consistency.

---

Patterns Better for Tokenized/Contextual Analysis

4. Shadow State Stores / Globals

• Patterns: window.sbi*, var ... = ...; // fallback
• Rationale: Detecting global state and fallback logic is more robust with token/context analysis, especially in JS/PHP.
• Practicality: Medium for GREP, High for tokenized scanner. GREP can catch some, but context is key to avoid false positives.

7. Hidden State Transitions in Non-FSM Paths

• Patterns: refresh_state(, transition(
• Rationale: Requires understanding call sites, function context, and FSM structure—better suited for tokenized/static analysis.
• Practicality: Low for GREP, High for tokenized scanner.

---

Real-World Accuracy & Value

• These patterns reflect real code quality and maintainability issues seen in production WordPress/JS codebases.
• They are actionable, not just theoretical, and will help catch regressions and architectural drift.
• The GREP patterns are broad by design, but with reviewer context, they are highly effective and pragmatic.
• The split between GREP and tokenized scanning is correct and practical.

---

Conclusion:

• Patterns 1, 2, 3, 5, and 6 are excellent candidates for the GREP scanner and should be added to the pattern library.
• Patterns 4 and 7 are best reserved for a more advanced, context-aware (tokenized) scanner.
• Your approach is honest, practical, and will provide real value in CI/code review.

If you want, I can help you draft the actual pattern library entries or regexes for these. Let me know if you’d like to proceed!

[noelsaw1]

Let me also check your existing pattern library to understand how these would fit:Good context. Let me give you a practical assessment of each proposed pattern:

---

Pattern-by-Pattern Analysis

1) Multiple Refresh Endpoints / Overlapping Actions

Patterns: sbi_refresh_repository, sbi_refresh_status

Verdict: ❌ Not worth including

The generic regex \b([a-z0-9_]+_)?refresh_(repository|status)\b is too narrow. This is a specific architectural smell in that codebase, not a universal WordPress antipattern. Most plugins won't have competing refresh endpoints—and if they do, the naming convention will vary wildly.

---

2) Mixed Rendering Paths

Patterns: row_html, rows_html, append(html), innerHTML =

Verdict: ⚠️ Partial value—innerHTML only

innerHTML = could be valuable as a heuristic pattern for two reasons:

• XSS risk signal (especially without sanitization)
• Duplicate rendering smell

However, row_html and append(html) are too vague—they'll match legitimate variable names and jQuery patterns.

Recommendation: Consider adding innerHTML\s*= as a LOW/heuristic pattern for JS code quality review, not as a definitive finding.

---

3) Inline Script for Core Actions

Patterns: <script> in PHP templates

Verdict: ✅ Worth considering

This is a legitimate code smell—inline scripts in PHP templates violate separation of concerns and bypass proper asset enqueueing. WordPress best practice is using wp_enqueue_script() and localized data via wp_localize_script().

Proposed implementation:

{
  "id": "inline-script-in-php",
  "title": "Inline <script> in PHP template",
  "severity": "MEDIUM",
  "type": "heuristic",
  "search_pattern": "<script[^>]*>",
  "file_patterns": ["*.php"],
  "exclude_patterns": ["*Test*.php", "*test*.php"]
}

The jQuery handler pattern ($(document).on('click') is too broad and would catch legitimate delegated event handlers.

---

4) Shadow State Stores / Globals

Patterns: window.sbi*, fallback vars

Verdict: ❌ Not for GREP scanner

ChatGPT's assessment is correct—this needs tokenized analysis. window. access is too common and legitimate for GREP to differentiate between proper namespace APIs and problematic shadow state.

---

5) Duplicate Diagnostics Panels

Patterns: debug, SSE/sse

Verdict: ❌ Far too noisy

debug will match thousands of legitimate uses: debugLog(), WP_DEBUG, $debug_mode, comments, etc. Not actionable.

---

6) Action Buttons Always Rendered

Patterns: Plugin-specific selectors

Verdict: ❌ Not generalizable

This is a DOM architecture review for that specific plugin. No generic WordPress pattern here.

---

7) Hidden State Transitions

Patterns: refresh_state(, transition(

Verdict: ❌ Too architecture-specific

Most WordPress codebases don't use formal FSMs. This requires code flow analysis, not string matching.

---

Summary Scorecard

Pattern	Practical?	Generalizable?	Worth Including?
1. Multiple Refresh Endpoints	✅	❌	No
2. Mixed Rendering (innerHTML)	✅	⚠️	Maybe (heuristic)
3. Inline <script> in PHP	✅	✅	Yes
4. Shadow State / Globals	❌	❌	No (needs tokenizer)
5. Duplicate Diagnostics	❌	❌	No (too noisy)
6. Action Buttons Rendered	❌	❌	No
7. FSM Transitions	❌	❌	No (needs tokenizer)

---

Recommended Action

Add one pattern now:

• inline-script-in-php — MEDIUM/heuristic, catches a real WordPress antipattern

Consider for future:

• innerHTML assignment — LOW/heuristic for JS files, signals XSS risk and rendering concerns

Defer the rest — they're either too plugin-specific or require the Golden Rules Analyzer's semantic analysis capabilities.

Want me to draft the JSON pattern file for inline-script-in-php?