Repository navigation
Add an evidence-based Query Loop configuration audit #215
Copy link
Copy link
Open
Labels
area: compatibilityWordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.WordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.area: performancePerformance-sensitive behavior, page weight, caching, preloading, or resource hints.Performance-sensitive behavior, page weight, caching, preloading, or resource hints.enhancementFeature or improvement request that changes product behavior or user experience.Feature or improvement request that changes product behavior or user experience.priority: mediumUseful or user-impacting work that should be planned but is not blocking now.Useful or user-impacting work that should be planned but is not blocking now.status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.Needs acceptance criteria, scope, UX, or technical design before implementation.
Milestone
Description
Summary
Add a read-only audit that inventories WordPress Query Loop block configurations and flags only evidence-based risk patterns.
This is a 2.0.0 advanced diagnostic layer, not a query profiler. It must distinguish static configuration findings from measured runtime behavior and must never rewrite content automatically.
Customer value
Non-technical owners can identify potentially expensive listing configurations and understand what to review, while advanced users receive the exact configuration evidence behind each recommendation.
Proposed scope
- Inventory Query Loop blocks from bounded public content and relevant block templates.
- Record safe configuration facts such as inheritance, post type, items per page, offset, ordering, sticky behavior, taxonomy filters, and pagination.
- Define conservative risk rules, for example unusually high item counts, large offsets, expensive ordering choices, or repeated similar loops on one view.
- Show the content/template reference, detected configuration, confidence, and a plain-language review action.
- Link to runtime slow-query evidence only when a separate bounded measurement exists.
Safety and scalability requirements
- Parse block attributes through WordPress block APIs; do not execute frontend queries to inventory configuration.
- Do not store post content, rendered HTML, raw SQL, private query parameters, or visitor data.
- Exclude or redact private content references unless the current administrator can access them.
- Scan in bounded batches with resumable progress and explicit refresh.
- Never edit blocks, templates, query arguments, or database indexes automatically.
Acceptance criteria
- A technical design lists supported attributes, risk rules, confidence levels, scan boundaries, exclusions, and copy.
- Findings clearly say
configuration auditand never imply measured slowness without runtime evidence. - Each finding links to an accessible owner review path and explains why it was flagged.
- Unsupported or dynamic query variations report
not assessedrather than a guessed result. - Scans are bounded, resumable, permission checked, and safe for multisite and large content sets.
- Tests cover inherited queries, custom post types, pagination, offsets, taxonomy filters, repeated loops, templates, private content, malformed blocks, and no-query-loop sites.
- No content is modified by the audit.
Validation and proof
- Fixture matrix for common and high-risk-looking configurations.
- Collection time and peak-memory benchmark on a high-content fixture.
- Desktop and narrow-width screenshots for no findings, findings, partial scan, and unsupported states.
- Security review of content references and permissions.
- Standard hosted checks remain green.
Dependencies
- Depends on Define a local site baseline inventory for performance guidance #214 for bounded content and post-type context.
- Research local slow query analysis and EXPLAIN-based guidance #185 owns temporary runtime query sampling and EXPLAIN research.
- Add plugin impact report for runtime and asset pressure #182 owns plugin-level impact attribution.
- Add Performance Health Dashboard with actionable optimization guidance #178 may summarize findings without duplicating the audit.
Non-goals
- Query execution tracing or database index recommendations.
- Automatic block edits.
- Declaring a Query Loop slow based only on its existence.
- Supporting every third-party query block in the first version.
Target and decision
- Target release: 2.0.0 advanced performance intelligence.
- Implementation base:
release/2.0.0.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area: compatibilityWordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.WordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.area: performancePerformance-sensitive behavior, page weight, caching, preloading, or resource hints.Performance-sensitive behavior, page weight, caching, preloading, or resource hints.enhancementFeature or improvement request that changes product behavior or user experience.Feature or improvement request that changes product behavior or user experience.priority: mediumUseful or user-impacting work that should be planned but is not blocking now.Useful or user-impacting work that should be planned but is not blocking now.status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.Needs acceptance criteria, scope, UX, or technical design before implementation.
Activity