fix: show every snippet on sites with more than a hundred by TallblokeUK · Pull Request #560 · codesnippetspro/code-snippets

TallblokeUK · 2026-09-16T12:34:37Z

Fixes the snippets list showing only the first 100 snippets on sites with larger libraries.

Reported at https://wordpress.org/support/topic/hiding-some-snipptes/

The problem

The manage screen embeds a list capped at min( $snippets_per_page, 100 ) snippets so the table paints immediately, then replaces it with the complete list from the REST API. That request carried every snippet's code, which is by far the largest thing the screen transfers and grows without bound with the library.

When the request does not land, the screen keeps the capped list, reports its length as the total, and gives no indication that anything is wrong. The type counts are derived from whichever list is loaded, so they agree with the truncation and look plausible. The admin bar counts come from a separate server-side query, which is how the reporter noticed the discrepancy.

This is why the report is hard to reproduce: it does not need more than 100 snippets, it needs the list request to fail. On a healthy site the screen corrects itself within a moment.

Changes

The list is requested without snippet code, via _fields. On a 135-snippet library the response drops from 294 KB to 45 KB. No server change is required.
The type counts use the values localised with the page until the complete list has actually arrived. The previous check treated the embedded list as though it were loaded, so the authoritative counts were never used.
A failed list request shows a notice rather than only reaching the console.
Searching snippet contents still needs the code, so it is fetched once, on the first search that could match it.
Cloning and previewing from the list resolve the snippet's body first, since the list no longer carries it. The preview editor now follows its code prop, having previously read the value only when it was created.

Verification

PHPUnit: 335 tests green. Includes a new test asserting the requested field list still matches the snippets schema minus code, so a property added to the schema cannot quietly stop reaching the browser. Confirmed it fails both when a field is dropped from the list and when code is added back.
Playwright: 68 tests green across the default and file-based projects, including five new scenarios. Confirmed the counts scenario fails against the previous logic.
Measured on a 144-snippet site: 45 KB list request; counts correct while the request is in flight; counts correct and accompanied by a notice when it fails.
ESLint, PHPCS and Stylelint clean.

Note

Why the reporter's request fails has not been established; their site is on shared LiteSpeed. A much smaller response makes it considerably more likely to succeed, but if the cause is the response being cached or filtered rather than its size, this will not resolve their site on its own. It will at least show them an error instead of a silently partial list.

The manage screen embeds a list capped at a hundred snippets so the table paints immediately, then replaces it with the complete list from the REST API. That request carried every snippet's code, which grows without bound with the library and is by far the largest thing the screen transfers, so it can fail on a constrained host. When it did, the screen kept the capped list, reported its length as the total, and said nothing. The list is now requested without code, taking a 135-snippet library from 294 KB to 45 KB. The type counts keep using the authoritative values sent with the page until the complete list has arrived, rather than counting whichever list happens to be present. A failed request now shows a notice instead of only reaching the console. Searching snippet contents still needs the code, so it is fetched once, on the first search that could match it.

The list no longer carries snippet code, so cloning from it produced an empty snippet and the preview opened on an empty editor. Both now resolve the snippet's body first. The preview editor also follows its code prop. It read the value only when it was created, so a body arriving afterwards was ignored.

Checks that the whole library is shown rather than the embedded subset, that the list request never asks for snippet code, that a snippet previewed from the list still shows its code, and that a failed list request leaves the counts telling the truth and says so on screen. Also checks the requested field list still matches the snippets schema, so a property added to the schema cannot quietly stop reaching the browser.

Resolved against the incoming pro-beta sync: - SnippetPreviewModal keeps both the new extraActions prop and the code resolution this branch adds, since a snippet opened from the list no longer arrives with its body. - SnippetsTable keeps this branch's comment explaining why the counts wait for the list to load before switching away from the localized values. - readme.txt follows core-beta in dropping the 4.0.0 section; the entry for this fix lives in CHANGELOG.md alongside the rest. The sync also added created_by and updated_by to the snippets schema, so the list now requests them. The schema test added on this branch is what caught their absence.

github-actions · 2026-09-16T13:28:50Z