How to Add a Live Search Bar to a WordPress Table

Updated July 2026 • 6 min read • By Fahad Murtaza

A live search bar lets users type a keyword and immediately see the matching rows, without submitting a form or clicking a button. For tables with large amounts of text content, names, descriptions, notes, addresses, it is often faster than any combination of dropdown filters. This guide covers how to enable live search in TableCrafter, how to configure which columns it searches, how different parts of the system handle request timing, and when to use global search versus per-column text filters.

How Do I Enable Live Search: The Shortcode Parameter?

TableCrafter's search bar is controlled by a single shortcode parameter:

[tablecrafter id="1" search="true"]

Adding search="true" renders a full-width search input above the table (and above any column filter bar if filters are also enabled). There is no builder toggle for search, it is purely a shortcode-level switch, which means you can enable it on some page embeds and hide it on others using the same table ID.

To combine search with filters and editing:

[tablecrafter id="1" search="true" filter="true" edit="true" export="true"]

Which Columns Are Searched?

By default, the global search bar searches every visible column that has a text-compatible data type. Numeric, date, and boolean columns are excluded from the default search scope because searching for "5" across a table with ID and quantity columns produces confusing matches.

The searchable column set is the union of all columns whose Searchable toggle is enabled in the table builder. To check or change this:

1. Open the table builder and click the column you want to include or exclude from search
2. In the column settings panel, find the Searchable toggle (distinct from the filter toggle)
3. Enable or disable it and save the column

Disabling the Searchable toggle on a column removes it from the global search scope without hiding it from the table or removing its column filter. A column can be filterable but not searchable, searchable but not filterable, or both.

How Does Search Debouncing Work?

Debouncing controls how frequently search triggers an AJAX request while the user types. The behavior in TableCrafter differs depending on which search mechanism you are using, and getting this distinction right matters for performance.

The per-table search bar enabled with search="true" does not fire on every keystroke. It fires only when the user clicks the search button or presses Enter. This design is intentional: the global search bar typically queries multiple text columns with a LIKE %term% condition, which is an expensive operation on large tables. Requiring an explicit submit keeps server load predictable.

Per-column text filter inputs behave differently. Each column filter input fires automatically 300 milliseconds after the user stops typing. This 300ms debounce is hardcoded in the frontend JavaScript. Typing quickly through several characters triggers only one request, not one per character, because the timer resets on each keystroke and fires only after the 300ms window closes without a new keystroke.

If you use the [gravity_global_search] cross-table search widget (a separate shortcode for searching across multiple tables simultaneously), it also uses a 300ms debounce on keyup. You can override this for that widget specifically via the debounce attribute: [gravity_global_search debounce="500"].

How Does Restricting Search to Specific Columns Work?

The Searchable column toggle described above is the primary tool for restricting search scope. However, there is also a shortcode parameter for runtime restriction:

[tablecrafter id="1" search="true" search_columns="name,email,company"]

The search_columns parameter accepts a comma-separated list of column slugs (the machine-readable key for each column, visible in the builder next to the column label). When this parameter is present, it overrides the Searchable column toggles for that specific embed. The same table could be embedded twice: once with broad search across all text columns, and once with search_columns narrowed to a single column for a focused use case.

What Is Global Search vs. Per-Column Text Filter: When to Use Each?

TableCrafter supports both a global search bar and per-column text filter inputs. They are not mutually exclusive, you can enable both simultaneously, but understanding their differences helps you choose the right tool for each use case.

A common pattern is to enable both: the search bar handles quick keyword lookups ("find anything with 'Chicago' anywhere") while per-column filters handle structured queries ("show only rows where Status = Active AND Region = Midwest"). This combination is covered in depth in the guide on combining search and column filters.

How Does Search Behavior at the Data Layer Work?

For Gravity Forms data sources, the global search translates to a field_filters block with mode: "any", meaning the entry matches if any of the specified fields contains the search term. For SQL-backed sources (WooCommerce, custom tables), it translates to a series of LIKE %term% conditions joined with OR. The search is case-insensitive in all cases.

The search term is sanitized before hitting the database: special SQL characters are escaped and the term is limited to 255 characters. Very long search strings are silently truncated at the server, so the user experience degrades gracefully rather than failing.

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

How Do Placeholder Text and Search Input Label Work?

The default placeholder text inside the search bar reads "Search..." This default comes from the plugin's label configuration. To change it globally for all tables on your site, navigate to TableCrafter → Settings → Labels and update the Search Placeholder field. Any value you enter there becomes the default placeholder for every table's search bar.

For per-table placeholder text, use the shortcode parameter search_placeholder to override the global default for a specific embed:

[tablecrafter id="1" search="true" search_placeholder="Search by driver name or load ID"]

The per-table parameter takes precedence over the global label setting. This means you can set a generic default globally and customize only the tables where context-specific language improves usability. A load-tracking table benefits from "Search by driver name or load ID" far more than a generic "Search..." placeholder, because it tells users exactly which columns they can search against.

There is no separate visible label element above the search bar by default. The placeholder text serves as the only label. If your audience relies on screen readers or you want to add a visible label for accessibility, you can add one via a custom block above the embed in the Gutenberg editor. The search input itself has a type="search" attribute and an ARIA label generated from the table title, so it is accessible to assistive technology without a visible label.

What Are the Next Steps?

Live search is the fastest way for users to find a specific record in a large table. Once it is working, consider enabling per-column filters alongside it using filter="true". The guide on combining search and column filters explains exactly how the two systems work together: the per-table search bar matches any column (OR logic across searched columns), while per-column filters apply AND logic across active filter inputs. When both are active simultaneously, a row must satisfy all active column filters AND match the global search term.

After search and filters are tuned, the next consideration for large tables is pagination and page size. The default page size controls how many rows load per AJAX request, which directly affects both response time and user experience for power users who are scanning through hundreds of records. The guide on tuning page size for performance explains the relationship between page size, query cost, and the user-selectable page size toggle that lets users adjust their own view density.

If your users return to the same filtered view repeatedly, sticky filter persistence is worth enabling. It saves filter and search state to localStorage so the table reopens in the same filtered state on the next visit, eliminating the need to re-apply filters on every session. The guide on sticky filters across page loads covers the localStorage and URL parameter options.