Set Products Per Page for WooCommerce: safe setup, failure cases, and rollback

Direct answer

WooCommerce offers no prominent core setting for this count; the theme usually owns it. To change it safely, return one bounded integer between 4 and 96 from WooCommerce's native products-per-page filter, only for front-end shop and product taxonomy archives. Verify the context before answering. Return the incoming value unchanged for admin screens, REST responses, feeds, shortcodes, widgets, blocks, builders, malformed state, or missing WooCommerce. Write nothing: no products, pagination templates, cookies, or visitor settings.

Set Products Per Page for WooCommerce follows that bounded-value boundary. Free saves one global number from 4 to 96 and returns it for native shop and product taxonomy archives. Pro, at $39 per year for one site with a 14-day trial, sets up to twenty-five category-specific numbers, each in the same range.

One number is not a pagination rebuild

A merchant who only wants twelve or forty-eight products per page does not need a customer-facing selector, cookie handling, or a pagination replacement.

Public support reports show the recurring pain. One merchant could not find a way to increase the number of products per page and asked for an answer that does not require a subscription. Another asked directly how to increase the products shown before pagination. A third, with more than one hundred products, reported the available products-per-page control stopping at one hundred. These reports document individual incidents only. They do not establish that every store or theme lacks a workable control.

Let WooCommerce and the theme own the count

The page size is a display input, not product data. WooCommerce applies it while building the archive query, and the theme supplies the default. A focused helper answers the same question with the owner's number and changes nothing else.

That rule prevents several dangerous shortcuts:

• Do not write products, terms, queries, pagination templates, cookies, orders, or customers.
• Do not add a customer dropdown, a show-all option, or column controls.
• Do not change admin, REST, feed, shortcode, widget, block, or page-builder queries.
• Do not rebuild pagination markup or load frontend JavaScript or CSS.
• Do not scan the catalog, schedule work, or run background jobs.

The settings write requires the exact manage_woocommerce capability and a valid nonce. A request that lacks either saves nothing, keeps the prior valid state, and makes no remote call.

Filter the number, not the page

WooCommerce applies the native loop_shop_per_page filter before it paginates a standard archive. The current wc-template-functions.php source shows where the page size is read. A narrow helper returns the saved integer there, after two checks: the value is between 4 and 96, and the request is a verified front-end shop or product taxonomy archive.

Every other context — admin lists, REST responses, feeds, shortcodes, widgets, blocks, builders — receives the incoming value exactly as WooCommerce passed it. Malformed, missing, or out-of-range state does the same.

Save the number and count the products

1. Open WooCommerce > Products Per Page.
2. Choose a number from 4 to 96 and save.
3. Open the shop page while signed out and count the products before pagination.
4. Open one product category archive and confirm the same count.
5. Confirm page two and beyond still work with native pagination markup.
6. Confirm admin product lists, feeds, and any builder grid keep their own counts.
7. Clear the setting and confirm the theme's native count returns immediately.

The settings screen uses labeled controls, works by keyboard at desktop and mobile widths, and announces state to screen readers.

The correct pass condition is one bounded number on standard archives. A helper that also ships a visitor selector or rewrites pagination is solving a wider job with a wider support surface.

Diagnose an unchanged count

Start with the native shop page. If the count is correct there, the filter works and the remaining surface is a non-standard context that is intentionally untouched. Do not clear every cache or disable every plugin before identifying which query owns the count.

Add bounded category numbers, not a visitor selector

Pro can set at most twenty-five category-specific values, each from 4 to 96, while every other archive uses the global Free number. There is no show-all option, no customer dropdown, and no pagination markup change.

If Pro or the license API is unavailable, the valid Free global value continues and category values are ignored.

Understand compatibility honestly

The per-page filter is a shared input surface. WooCommerce's standard archives read it, but a page builder, shortcode, widget, feed, or remote client does not have to.

A safe product promise is therefore:

• native shop and product taxonomy archives use the saved number while it is set;
• every non-archive context receives the incoming value unchanged;
• a cleared or malformed setting returns the theme's native count immediately;
• no product, query, pagination template, cookie, or visitor setting is ever written.

This is more useful than claiming the count changes everywhere, which cannot be proven across an open plugin ecosystem.

Test failure and rollback

Release acceptance should cover:

1. In-range values on native shop and taxonomy archives.
2. Values below 4, above 96, and malformed state returning the incoming value.
3. Admin, REST, feeds, shortcodes, widgets, blocks, and builders staying native.
4. WooCommerce missing causing no fatal error.
5. Pro or the license API unavailable leaving the Free global value active.
6. Update, downgrade, rollback, deactivation, and uninstall.
7. Unchanged products, terms, queries, pagination templates, cookies, orders, and customers.

When WooCommerce is missing or inactive, the plugin registers no settings page or filter and shows one dismissible admin notice. There is no fatal error and no public change.

Because nothing is written, rollback is immediate. Clear the setting or deactivate, and the theme's native count returns with no residue. Uninstall removes only the plugin's own settings.

Resource boundary

Answering one filter needs at most two owned option reads per request and one integer return. It does not need a second query, a cron event, a custom table, a background job, JavaScript, a stylesheet, a storefront remote request, or idle work. Measure the real hosting stack before a high-traffic launch.

The plugin stores no personal data and sends no telemetry. Pro contacts the StoreFixKit license and update API only from authenticated admin requests.

Common mistakes

Pasting a snippet into functions.php

The snippet becomes code you own. It breaks quietly when themes or WooCommerce change how archives are built.

Hunting for a hidden core setting

There is no prominent core control; the theme owns the default. The missing setting is the problem, so answer the filter instead of searching menus.

Installing a per-page suite for one number

A suite adds dropdowns, cookies, and scripts for visitors. An owner who wants one fixed number carries none of that.

Choosing show-all or an unbounded number

A page with hundreds of products loads slowly and buries buyers. The 4-to-96 bound exists so one mistake cannot flatten the catalog.

Replacing pagination markup

The number is one input to the existing pager. Rebuilding the pager takes over theme markup for no benefit.

Market boundary

The official WooCommerce Marketplace lists a current Product Per Page offer at $29 per year; the listing reports 100+ active installs. An established WordPress.org plugin for the same job reports 10,000+ active installs. That proves an active category. It does not prove demand or revenue for a narrower owner-only setting, and none of these counts is a payer count.

The commercial hypothesis is that some nontechnical merchants prefer one bounded number over a snippet or a visitor-facing suite. Measure StoreFixKit installs, setup completion, verified counts, trial starts, paid conversions, refunds, renewals, and support load. A competitor's price or install count is not StoreFixKit traction.

FAQ

Where is the products-per-page setting in WooCommerce?

Core exposes no prominent setting; the theme usually owns the count. A safe change returns one bounded integer from the native filter for shop and product taxonomy archives.

Can shoppers choose their own number of products per page?

Not in this design. A visitor dropdown needs cookies and frontend assets. The owner chooses one bounded number, and every visitor sees the same page size.

What happens when the setting is cleared or the plugin is deactivated?

The filter returns the incoming value and the theme's native count comes back immediately. If only Pro or licensing is unavailable, the valid Free global number continues.