Claude Skill

jsf-overview

Map a JetSmartFilters integration to the correct filter, provider, query ID, listing, frontend event, or extension API. Use when planning or reviewing JSF compatibility, diagnosing a filter that targets the wrong listing, choosing between JSF Listing hooks and a custom provider,

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download lonsdale201-wp-agent-skills-jetsmartfilter_jsf-overview-52f6020.zip · 2 KB
Part of lonsdale201/wp-agent-skills — 226 skills

Install

skills CLI npx skills add https://github.com/Lonsdale201/wp-agent-skills/tree/main/jetsmartfilter/jsf-overview
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install lonsdale201-wp-agent-skills@llmmart
Git git clone https://github.com/Lonsdale201/wp-agent-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole lonsdale201/wp-agent-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

JetSmartFilters integration map

Use this as the router for JetSmartFilters work. Keep a single identity pair, provider/queryId, from the filter controls through the request and the rendered listing.

Mental model

filter control -> filter group (provider/queryId) -> parsed query args
               -> provider renders content -> frontend replaces/inserts DOM
Layer Owns Use
Filter User input and query-variable mapping Existing JSF filter types and their settings
Filter group All controls targeting one provider/query ID Frontend state, AJAX, pagination, active filters
Provider Locating and re-rendering the target HTML/data Built-in provider or a registered custom provider
Query Turning filter values into query arguments Listing-specific filters or JSF query hooks
Listing Initial query, item card, pagination statistics JSF Listing, JetEngine Listing Grid, Woo archive, or another supported renderer
Frontend events Loading state and post-render compatibility jsf-frontend-events

Choose the narrowest extension point

  • Configure a normal JSF Listing: use jsf-listing-integration.
  • Run JavaScript when AJAX starts or finishes: use jsf-frontend-events.
  • Modify which records a listing returns: use jsf-query-hooks.
  • Expose an unsupported renderer or data source: use jsf-custom-provider-query.
  • Do not create a custom provider merely to add one query condition. Providers own DOM replacement; query hooks own record selection.

Identity rules

  • A provider ID identifies a renderer, not a specific widget. The native JSF Listing provider is jsf-listing.
  • The query ID identifies one instance of that provider. JSF defaults missing IDs to default.
  • Every filter, pagination control, active-filter control, and listing intended to work together must resolve to the same pair.
  • Two listings using the same provider need distinct query IDs. Otherwise requests, stored defaults, props, and frontend groups can collide.
  • Scope PHP and JavaScript integrations by both values whenever both are available.

Compatibility workflow

  1. Record the plugin version and the target renderer.
  2. Inspect the listing's provider and query ID in rendered attributes and window.JetSmartFilterSettings.
  3. Verify the filter's content provider, query ID, apply type, and query variable.
  4. Confirm the initial query works before testing AJAX.
  5. Inspect the jet_smart_filters request and JSON response.
  6. Verify DOM replacement, pagination props, empty results, rapid changes, and browser history.
  7. Re-test source-derived hooks after a JSF upgrade; the frontend event bus is shipped in a minified bundle and is not a WordPress core API.

Source-verified boundaries

The public frontend script is enqueued only when a filter marks JSF as used. JetSmartFilterSettings then contains provider selectors, default queries, provider settings, and pagination props. A companion script must therefore feature-detect window.JetSmartFilters and should load only on pages that use filters.

References

Verified against JetSmartFilters 3.8.3.1 source:

  • jet-smart-filters.php:151-219,225-299
  • includes/filters/manager.php:22-112
  • includes/data.php:198-228
  • includes/providers/manager.php:78-146
  • includes/providers/jsf-listing.php:33-220
  • assets/js/public.js
Files (wp-agent-skills)
  • agents
    • openai.yaml 286 B
      interface:
        display_name: "JetSmartFilters Overview"
        short_description: "Choose the correct JetSmartFilters integration surface."
        default_prompt: "Use $jsf-overview to map this JetSmartFilters integration to the correct provider, query, listing, frontend event, or extension API."
      
  • SKILL.md 4.1 KB
    ---
    name: jsf-overview
    description: >-
      Map a JetSmartFilters integration to the correct filter, provider, query ID,
      listing, frontend event, or extension API. Use when planning or reviewing JSF
      compatibility, diagnosing a filter that targets the wrong listing, choosing
      between JSF Listing hooks and a custom provider, or encountering
      JetSmartFilters, JetSmartFilterSettings, jsf-listing, content_provider, or
      jet-smart-filters hooks without knowing which layer owns the behavior.
    metadata:
      wp-skills-author: "Soczó Kristóf"
      wp-skills-contact: "mailto:lonsdale201@hotmail.com"
      wp-skills-plugin: "jet-smart-filters"
      wp-skills-plugin-version-tested: "3.8.3.1"
      wp-skills-php-min: "7.4"
      wp-skills-last-updated: "2026-07-21"
    ---
    
    # JetSmartFilters integration map
    
    Use this as the router for JetSmartFilters work. Keep a single identity pair,
    `provider/queryId`, from the filter controls through the request and the
    rendered listing.
    
    ## Mental model
    
    ```text
    filter control -> filter group (provider/queryId) -> parsed query args
                   -> provider renders content -> frontend replaces/inserts DOM
    ```
    
    | Layer | Owns | Use |
    |---|---|---|
    | Filter | User input and query-variable mapping | Existing JSF filter types and their settings |
    | Filter group | All controls targeting one provider/query ID | Frontend state, AJAX, pagination, active filters |
    | Provider | Locating and re-rendering the target HTML/data | Built-in provider or a registered custom provider |
    | Query | Turning filter values into query arguments | Listing-specific filters or JSF query hooks |
    | Listing | Initial query, item card, pagination statistics | JSF Listing, JetEngine Listing Grid, Woo archive, or another supported renderer |
    | Frontend events | Loading state and post-render compatibility | `jsf-frontend-events` |
    
    ## Choose the narrowest extension point
    
    - Configure a normal JSF Listing: use `jsf-listing-integration`.
    - Run JavaScript when AJAX starts or finishes: use `jsf-frontend-events`.
    - Modify which records a listing returns: use `jsf-query-hooks`.
    - Expose an unsupported renderer or data source: use
      `jsf-custom-provider-query`.
    - Do not create a custom provider merely to add one query condition. Providers
      own DOM replacement; query hooks own record selection.
    
    ## Identity rules
    
    - A provider ID identifies a renderer, not a specific widget. The native JSF
      Listing provider is `jsf-listing`.
    - The query ID identifies one instance of that provider. JSF defaults missing
      IDs to `default`.
    - Every filter, pagination control, active-filter control, and listing intended
      to work together must resolve to the same pair.
    - Two listings using the same provider need distinct query IDs. Otherwise
      requests, stored defaults, props, and frontend groups can collide.
    - Scope PHP and JavaScript integrations by both values whenever both are
      available.
    
    ## Compatibility workflow
    
    1. Record the plugin version and the target renderer.
    2. Inspect the listing's provider and query ID in rendered attributes and
       `window.JetSmartFilterSettings`.
    3. Verify the filter's content provider, query ID, apply type, and query
       variable.
    4. Confirm the initial query works before testing AJAX.
    5. Inspect the `jet_smart_filters` request and JSON response.
    6. Verify DOM replacement, pagination props, empty results, rapid changes, and
       browser history.
    7. Re-test source-derived hooks after a JSF upgrade; the frontend event bus is
       shipped in a minified bundle and is not a WordPress core API.
    
    ## Source-verified boundaries
    
    The public frontend script is enqueued only when a filter marks JSF as used.
    `JetSmartFilterSettings` then contains provider selectors, default queries,
    provider settings, and pagination props. A companion script must therefore
    feature-detect `window.JetSmartFilters` and should load only on pages that use
    filters.
    
    ## References
    
    Verified against JetSmartFilters 3.8.3.1 source:
    
    - `jet-smart-filters.php:151-219,225-299`
    - `includes/filters/manager.php:22-112`
    - `includes/data.php:198-228`
    - `includes/providers/manager.php:78-146`
    - `includes/providers/jsf-listing.php:33-220`
    - `assets/js/public.js`
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related