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,
Install
npx skills add https://github.com/Lonsdale201/wp-agent-skills/tree/main/jetsmartfilter/jsf-overview
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install lonsdale201-wp-agent-skills@llmmart
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
- Record the plugin version and the target renderer.
- Inspect the listing's provider and query ID in rendered attributes and
window.JetSmartFilterSettings. - Verify the filter's content provider, query ID, apply type, and query variable.
- Confirm the initial query works before testing AJAX.
- Inspect the
jet_smart_filtersrequest and JSON response. - Verify DOM replacement, pagination props, empty results, rapid changes, and browser history.
- 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-299includes/filters/manager.php:22-112includes/data.php:198-228includes/providers/manager.php:78-146includes/providers/jsf-listing.php:33-220assets/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.
Reviews (0)
No reviews yet.
No comments yet.