Data Tables Filters In Ajax Mode Disabled

Beta
#1

Hi Charlie,

Just wondering if filtering is either broken, or deliberately unavailable when Data Tables are in Ajax mode?

I have finally managed how to get Ajax filtering working properly on a site, which is perfect for Data Tables. Filtering works fine in Client Mode, but as soon as it is switched to Ajax, all filters disappear.

I have constructed a workaround, using CS Forms to do the filtering and feed the filters back into Data Tables via its Looper Provider’s Custom JSON. This works fine, but is not fully native to Data Tables, hence my question about whether filters are meant to be disabled when in Ajax mode. Here is my temporary page showing the frontend filtering. More in a Secure Note. https://staging.rememberthefallen.co.uk/nurses-table/

Thanks,
Christopher

#2

Just wondering if you have any thoughts on this one?

#3

New details in SN!

#4

Yeah so it is partially disabled. The problem being that grabbing all available filter options in an AJAX Datatable means grabbing all possible options. It’s a little advanced and would require caching the results behind the scenes, but I can take another look now that the plugin is released. I’ll take a look at your plugin and see if we can add some useful features into Datatables, but I can tell it’s a little hardcoded to what your site needs. Very cool you were able to get this up and running through extensions. Have a great weekend.

#5

Hey Charlie,

The site is one of the simplest in terms of displaying data, but one of the most complex and data-heavy in reality. I hope it give you a real-world use for the wonderful Data Tables - and a shift away from Search & Filter and FacetWP, using native Cornerstone features.

You are right, the plugin Claude created on our mutual (multi-day!) investigation to the Ajax problem is hardcoded to this specific site, which in its own is a one-off. However, I hope it guides you to a universal way forward for any Ajax cases!

If the Ajax use-case documentation could be increased significantly, it would also be much welcomed - Claude was required to work out many steps along the way in this project!

Have a restful weekend,
Christopher

#6

Hi Charlie,

A bit of a follow-up. Thanks for taking a look, and fair point - it is definitely built around what Remember The Fallen needs. The site-specific part is really just where the filters are configured, though. The mechanics underneath should generalise quite well, so in case it’s useful, here’s how I approached it:

  1. Filter sources in the builder. In my version the taxonomies or meta key for each filter are declared in PHP. In Data Tables they could be controls on each header cell, alongside Order Column, letting you pick one or more taxonomies or a meta key. The server would build its allowlist from the saved element data, so visitors can only filter by what’s been configured.

  2. Cached options. This is the piece you mentioned. I use a single DISTINCT query for terms actually used by published posts of the looper’s post types, stored in a transient and cleared on save_post, set_object_terms and term edits. It’s quick even on the casualty table’s 16,500 records.

  3. Several taxonomies per filter. Our ranks and units are split across army, naval and air force taxonomies, so each filter matches any of its taxonomies (OR), and terms with the same name are merged into one option. I suspect plenty of other sites structure data the same way.

  4. Selections in the URL. Filters are stored as query parameters, so your existing fetch picks them up unchanged, and filtered views become shareable and survive a reload. The extra tax_query clauses are appended rather than wrapped, so named meta_query ordering clauses keep working.

  5. Search within long option lists. A small search box above any list with more than 10 options keeps big lists usable.

Thanks as ever,
Christopher