How Pagination Works with Active Filters in TableCrafter

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

Pagination and filtering are both essential for navigating large datasets, but they need to coordinate precisely to avoid confusing results. TableCrafter handles this coordination automatically, resetting page position whenever a filter changes and recalculating row counts against the filtered set rather than the full entry pool. Understanding exactly how this works helps you build better table configurations and avoid common pitfalls when your users combine multiple active filters with custom page sizes. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native. WordPress plugin activation rates are highest in the first 48 hours after a feature update (WP Engine Developer Survey, 2024).

What Is the Core Behavior: Filters Narrow the Dataset, Pagination Slices It?

When a visitor loads a table built with TableCrafter, the plugin fires an AJAX request to wp-admin/admin-ajax.php that carries all active filter values, the current page number, and the configured rows-per-page setting. On the server side, TableCrafter applies filters first, building a constrained query against the underlying data source (Gravity Forms entries, Google Sheets rows, REST API payloads, etc.), and then applies LIMIT and OFFSET values to that already-filtered result set.

This ordering is intentional and important: pagination always operates on the filtered count, not the total entry count. If your Gravity Forms data source contains 2,400 entries but an active filter reduces that to 87 matches, the pagination UI will show page counts based on 87 records. A 25-row-per-page configuration will yield four pages, not 96.

What Happens When a User Changes a Filter?

The most critical moment in this interaction is when a user modifies a filter while already viewing page 3 or higher. Without automatic page reset, changing a filter on page 3 could return zero rows even if matches exist, because the offset would skip past the entire filtered result set.

TableCrafter prevents this with a deliberate reset-to-page-one rule: any change to a filter input resets the active page index to 1 before the next AJAX request fires. This applies to every filter type available:

• Text search fields (column-level and global search)
• Dropdown filters for choice-based fields
• Pro Multi-select filters for fields that accept multiple values
• Pro Date range pickers
• Pro Numeric range inputs for data bar columns

The reset happens client-side, in TableCrafter's frontend JavaScript bundle, before the debounce delay fires. So even if a user types quickly into a search field and the debounce is absorbing keystrokes, every pending request will carry page 1 as the starting position.

How Do Rows-Per-Page Configuration and How It Interacts with Filter State Work?

TableCrafter exposes a rows-per-page setting in the table builder admin under TableCrafter → Tables → [your table] → Display Settings. The value set there becomes the default per_page parameter sent with every request. If you enable the rows-per-page dropdown that appears in the table UI, visitors can override this value at runtime.

Changing the rows-per-page selector is treated the same as changing a filter: it resets the active page to 1 and fires a fresh AJAX request. This prevents the same offset-overflow problem described above. For example, if a user is on page 4 of a 10-row-per-page table and switches to 50 rows per page, TableCrafter will not attempt to show "page 4" of a now much-smaller page set, it returns to page 1 of the 50-row view instead.

The column mapping you define here is stored as a JSON configuration in the WordPress database. You can export this configuration using the TableCrafter export tool and import it to another table or another site. This is useful when replicating a table layout across multiple pages or when migrating a table to a staging environment for testing before going live.

What Is Multiple Active Filters: Intersection Logic and Running Counts?

When two or more filters are active simultaneously, TableCrafter applies them as AND conditions: only rows that satisfy every active filter appear in results. The pagination count reflects this intersection, not any individual filter's match count.

Consider a Gravity Forms table tracking trucking loads with columns for Driver, Status, and Date. If a user filters by Driver = "Maria Santos" (returning 120 rows) and then adds Status = "Delivered" (returning 45 of those 120), the pagination controls will recalculate against 45 rows the moment the second filter is applied. The page counter, the "Showing X–Y of Z results" summary, and the next/previous button states all update in that same AJAX response.

Pro Advanced filter combinations, including multi-select values on the same column, are also intersected at the query level, so selecting three statuses from a multi-select filter returns rows matching any of those three statuses, while the Driver filter continues to AND against that result. This union-within-column, intersection-across-columns behavior mirrors how spreadsheet tools like Excel handle multi-criteria filtering.

What Is Lookup Fields and Pagination: What to Watch For?

Pro Lookup fields resolve IDs to human-readable labels at render time. For example, a numeric user ID in a Gravity Forms entry becomes a visible display name in the table cell. This resolution happens after the AJAX query returns, which means filters on lookup columns filter against the raw ID values stored in Gravity Forms, not the displayed labels.

If you have a lookup column that resolves user IDs to names, and you add a text filter on that column, users typing a name into the filter will not match records, because the stored values are numeric IDs. For filterable lookup columns, use the dropdown filter type instead: TableCrafter pre-builds the option list from resolved labels and maps each selection back to its underlying ID before sending the AJAX query. This way pagination against filtered lookup data works correctly without any special configuration on your part.

To set this up, open the column editor for your lookup field in the table builder and set the filter type to Dropdown. TableCrafter will automatically populate the options from the resolved label set and handle the ID-to-label translation in both directions.

How Does Shortcode Configuration for Pagination with Filter Support Work?

TableCrafter's three equivalent shortcodes all accept pagination-related attributes directly:

[tablecrafter id="42" per_page="25" show_pagination="true" show_filter="true"]

You can also use the legacy aliases:

[tablecrafter id="42" per_page="25"]
[tablecrafter id="42" per_page="25"]

All three map to the same handler and produce identical output. The per_page attribute sets the initial page size. If you do not include a per_page attribute, the value configured in the table builder admin is used. Setting per_page in the shortcode overrides the admin setting for that specific embed without changing the saved configuration.

For tables embedded on pages with heavy caching (via plugins like NitroPack or WP Rocket), be aware that the initial HTML shell of the table is cacheable, but all filter and pagination interactions go through uncached AJAX requests to wp-admin/admin-ajax.php. This means your cached page load is fast, and filtering/paginating remains always-fresh and always-accurate.

What Is Free Tier vs Pro: What Is Available at Each Level?

Free The free tier of TableCrafter, available on WordPress.org, includes basic pagination (next/previous controls, rows-per-page selector) and global text search. Pagination resets on search input exactly as described above. You can display any number of rows across unlimited tables and columns.

Pro Pro unlocks column-level filters (dropdown, multi-select, date range, numeric range), which are where the multi-filter intersection logic described in this article becomes most useful. Accurate filtered pagination matters most for large datasets: tables with tens of thousands of rows benefit most because full-dataset display is never practical at that scale.

Other Pro features that interact with pagination include auto-refresh (the table reloads at a configurable interval and returns to the current page and filter state rather than resetting to page 1) and Pro role-based permissions (which limit which rows a given user can see, effectively pre-filtering the dataset before pagination is applied).