System
Catalogues → Filters → System holds the plugin’s settings and its working lists. The setting forms (Admin filter, Storefront filter, Value lists, Compatibility, Insights, Retention) are described in Options and Shop settings. This page covers the rest.
Performance
Section titled “Performance”Filters → System → Performance shows what the panel costs the shop and sets the limits that keep listings fast. Its settings apply to all sales channels; click Save after a change.
Settings
Section titled “Settings”| Setting | Effect |
|---|---|
| Limit of count queries | On MySQL, the most count queries the first answer of a listing runs (default 12, 2 to 40). Groups past the limit get their counts once the panel has loaded, in one request of their own. The limit shortens the first answer; without the HTTP cache the database does the same work, in two requests. On OpenSearch every count goes out in one request and the limit does not apply. |
| Lazy counts for hidden groups | Read only here: the shop defaults’ Hidden groups load setting, and how many sets have their own value. When opened: the groups under “More filters” come as their heads alone, and their values and counts load when the shopper opens them; a group with a choice is always counted. Change in the shop defaults opens the defaults in the builder. |
| HTTP cache | Always on, read only: the cache tags the pages with the panel carry, and what clears each (publishing the set, publishing the shop defaults, saving an assignment, publishing a skin or a channel’s skin, changing a source or its values), at once or with the shop’s cache queue. Publishing a set clears only its own pages. |
| Draft preview | Always on, read only: a draft lives under its preview token for a few minutes and never goes into the HTTP cache. |
| Collect times | Off by default. Each listing with the panel counts into a histogram by hour, set and time, written once the response is out. Nothing about the shopper is kept. Only requests outside the HTTP cache are counted: a page from the cache never reaches the shop’s code. The times are kept as long as Retention → Days the listing times are kept says. |
| Target time T | 100, 200 (default), 400 or 800 ms. Apdex counts a listing up to T as satisfied and up to 4T as tolerating; a listing past 4T goes to the slowest requests. |
| One slow request per channel every (s) | After a slow request is written, the channel’s next ones wait this long, so a bad minute does not fill the list with one page. Default 60, 10 to 3600. |
| Clear data | Removes the times collected and every slow request kept. The settings stay. |
Search engine
Section titled “Search engine”The card names the engine the shop counts on, MySQL (DAL) or OpenSearch, as detected. Estimate for switches the estimates below to the other engine, to see how it would be there; times are measured only on the engine the shop counts on.
Cost of the counts per request
Section titled “Cost of the counts per request”One row per published set, worked out with every group chosen: Groups (visible and hidden), Count queries against the limit, Counted later and State (OK, Near the limit, Past the limit by … groups). With collected times, the p50 and p95 of the first answer over 24 hours show too, else the set’s last measurement. A limit changed but not saved yet is used for the estimate at once.
Clicking a set shows the detail: how many count queries its first answer runs without a choice and with a value in every group, which hidden groups are counted on opening, which groups are past the limit (with the ways out: a higher limit, fewer groups at once, or OpenSearch), and the Apdex from the traffic.
Measure runs the set’s listing on a page of a channel as a guest gets it, without the HTTP cache: pick the Sales channel, the Page (a Category or a Search term) and the Runs, then Measure. It runs in the background with a value in every group; each run measures the first answer and the request for the groups past the limit. A measurement stops after 20 seconds with the runs so far. The set’s last measurements are listed under the form.
Slowest requests
Section titled “Slowest requests”While Collect times is on, the listings past 4T: when, the set, the channel and address, the time, the count queries and the kind of request (Page load, Change, Groups past the limit, More values). A row’s menu offers Measure this page and Check the page (Where sets show).
Filters → System → Tasks lists the long operations that run in the background, a batch at a time, also with the browser closed: URL names of values, Values hidden or pinned, Values merged, Values check, Issues (the overview check) and Performance measurement.
| Column | Shows |
|---|---|
| Task | What it does. |
| State | Waiting, Running, Done, Failed or Cancelled. |
| Progress | How far it is. |
| Started by | The user, or The shop for a task the shop started itself. |
| Started | When. |
The list can be filtered by state, task and start date. A running task’s menu has Cancel task; what it did so far stays. Ended tasks can be deleted from the list; what they did in the shop stays. Ended tasks are deleted after the days set under Retention → Days ended tasks are kept.
A screen that starts a task shows its progress in a window. The window can be closed: the task goes on, and this list shows how far it is. A task the shop stopped hearing from is picked up again after five minutes, and ends as failed when it stays silent; see Retention → Stalled tasks in Shop settings.
Versions
Section titled “Versions”Filters → System → Versions lists every published version of the filter sets, the shop defaults, the skins and the channels’ skin adjustments. Each publication saves one.
| Column | Shows |
|---|---|
| Object | The set or skin, and what it is. |
| Version | The number; the one the shop shows is marked current. |
| Who, When | Who published it, and when. |
| Changes | How many changes it made against the version before. |
| Comment | The comment given on publishing. |
Search by name, person or comment, or show only filter sets or skins. A row offers:
- Compare with the previous version: the differences, side by side;
- Restore as draft: the version becomes the draft, replacing the unpublished changes. The shop changes only when it is published again. A built-in skin cannot be restored, nor can the current version.
Versions can be deleted; a deleted version cannot be restored afterwards. The current version always stays. How many versions are kept per set and skin is set under Retention → Versions kept per set and skin.
Issues
Section titled “Issues”Filters → System → Issues lists every row the overview check found, the heaviest first: what keeps the filter sets, the landing pages and the compatibility catalogues from working as they should. The dashboard shows the first five; each kind of issue and its fix is explained in Overview.
| Column | Shows |
|---|---|
| Level | Error, warning or note. |
| Issue | The issue in words. |
| Kind | What kind of issue it is. |
| Set | The set it is about, if any. |
| Sales channels | The channels it concerns. |
Search by set, group, channel, landing page or catalogue, or filter by level, kind, set and sales channel. A row’s menu leads to where the issue is fixed. The check runs when the screen opens; Check again runs it at once.
Information
Section titled “Information”Filters → System → Information shows the plugin’s version, the product search the shop uses (MySQL or Elasticsearch / OpenSearch) and whether the plugin is compatible with the shop’s Shopware version.
Extensions taking over the filter panel lists active extensions that replace Shopware’s Listing script or the filter panel’s templates, with the file each replaces. Such an extension may still work beside P2LabFilter. When the panel does not draw or does not filter, switch the extension off on a test channel to see whether it is the cause.