Skip to content

Add an evidence-based Query Loop configuration audit #215

Open

Description

@mehul0810

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 audit and 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 assessed rather 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

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.

Activity

  1. added this to the Backlog milestone on Jul 24, 2026
  2. self-assigned this
    on Jul 24, 2026
  3. added
    enhancementFeature or improvement request that changes product behavior or user experience.
    area: compatibilityWordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.
    area: performancePerformance-sensitive behavior, page weight, caching, preloading, or resource hints.
    priority: mediumUseful 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.
    on Jul 24, 2026
  4. modified the milestones: Backlog, 2.0.0 on Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area: compatibilityWordPress, PHP, multisite, WooCommerce, theme, or plugin compatibility.area: performancePerformance-sensitive behavior, page weight, caching, preloading, or resource hints.enhancementFeature 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.status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions