The 4.2 line, three real features and five quiet stabilisations

The 4.2 line shipped over a few months in eight tagged versions. Three of those carry features substantial enough to deserve their own narrative; five are the kind of careful, narrow fixes that show up only when something breaks in a specific stack. This post bundles the lot, full notes per version, ordered as they shipped.

v4.2.55, Flip responsive mode#

Mobile responsive design has historically been a fork in the road: either render mobile cards (one row per card, stacked) or scroll horizontally. Both have weaknesses. Cards lose the row-comparison affordance; horizontal scroll requires constant thumb-work to read across.

The “Flip” mode is a third option. At a configurable breakpoint (default 768 px), the table reflows so the first column becomes a persistent row label running down the left side, and all other columns appear inline next to their column-header label, one column-pair per row.

You read it the way you’d read a vCard: name, then a label-value list of attributes. The row-comparison affordance survives because you can still scroll vertically through the persistent labels.

Accessibility is treated explicitly: row-headers are semantic role="rowheader", and data-label attributes carry the column header text into the inline rendering for screen readers.

[gravity_table id="42"
  responsive_mode="flip"
  flip_breakpoint="768"
  ...]

v4.2.54, Top-N rows display#

Sometimes you want a leaderboard, not a paginated list. “Top 10 customers by lifetime value.” “Top 5 most-overdue invoices.” “Bottom 3 products by margin.”

The new top_n settings handle this server-side, in the get_entries AJAX handler. Three knobs:

• top_n_count, how many rows
• top_n_column, which column ranks them
• top_n_direction, asc for bottom-N, desc for top-N

Crucially, the limit applies before pagination, search, and export. Search inside the top-10 narrows further; export of the top-10 emits exactly those 10 rows (not the full underlying table). It’s a true display-layer slice, not a per-page cap.

v4.2.53, Transpose table action#

For tables built manually (not from a Gravity Form), the columns-and-rows axis is sometimes assigned wrong on first build. The new Transpose action in the admin builder swaps them, what was a row becomes a column header, and vice-versa.

Implementation notes:

• Confirmation dialog before commit (the operation is destructive in the visual sense)
• New gt_transpose_table AJAX endpoint, secured with nonce + manage_options capability
• Transpose state stored in the table settings and exposed to the frontend template, so the rendered output reflects the swapped axes immediately

For Gravity-Forms-fed tables, transpose isn’t meaningful, the form fields define the columns. The action is hidden from the admin UI for those table types.

v4.2.52, Divi compatibility fatal fix#

Some incidents are debugger-friendly; this one wasn’t. Sites running Gravity Tables but not running Divi were taking a PHP fatal on every page load, including WordPress’s internal site search, which is what made it visible at all.

Root cause: class GT_Divi_Module extends ET_Builder_Module was declared at file scope without a class_exists('ET_Builder_Module') guard. When Divi wasn’t loaded, the extends-clause resolved to a missing class and PHP fataled.

Fix is one line, the canonical pattern WordPress plugin authors should use whenever extending a third-party plugin’s class:

if (class_exists('ET_Builder_Module')) {
    class GT_Divi_Module extends ET_Builder_Module { /* ... */ }
}

If your site never had Divi, the fix is invisible. If it had Divi at some point and was deactivated, the upgrade silences a recurring fatal you may have been seeing in the error log without knowing the source.

v4.2.51, Multi-table-per-page config fix#

A subtle bug that only manifested on pages with two or more Gravity Tables shortcodes. The second (and any subsequent) tables would inherit incorrect settings from the first table’s render context, occasionally skipping the JS initialisation entirely and breaking pagination.

Root cause: a self-referential read of $table_config at the bottom of templates/table.php for the enable_vertical_scroll and vertical_scroll_max_height keys, the variable held stale state from the previous shortcode call. Removing the duplicated reads fixed it.

If you’ve avoided putting multiple tables on a single page because something seemed off about the second one, this is the version where that constraint goes away.

v4.2.50, Horizontal-scroll cell width fix#

Tables with horizontal_scroll: true were rendering cells at unintentionally inflated widths because the desktop table-layout: fixed; min-width: 100% rule was applying to all wrappers, not just the non-scroll ones.

The fix introduces a gt-horizontal-scroll wrapper class that’s added when the setting is on; the desktop fixed-layout rule is now scoped to wrappers without that class. Horizontal-scroll tables use width: max-content, so cells retain their natural widths and the scroll affordance works correctly.

Visually: tables that already worked still work. Tables that looked stretched-out on desktop now look properly proportioned.

v4.2.49, Graceful unknown-table-type handling#

Before this fix, configuring a table with an unrecognised data-source type, e.g. a setting copied from a paid integration that wasn’t installed, caused a fatal during render.

The new GT_Shortcode guard returns a graceful HTML fallback instead. Admins see an actionable notice identifying the missing source-type by name; visitors see a generic “this content is temporarily unavailable” message. The fatal goes away.

This is a defence-in-depth fix more than a feature, but in the rare case you hit it during a partial migration, it changes “the page is broken” to “this one block is missing” which is much easier to triage.

v4.2.48, Late _load_textdomain_just_in_time fix for WP 6.7+#

WordPress 6.7 tightened the timing rules for load_plugin_textdomain(): calling it from a plugins_loaded callback now triggers the _load_textdomain_just_in_time notice every page load.

The fix moves the call into a standalone gt_load_textdomain() function hooked to init instead. Functionally identical translation behaviour; the notice goes away. If you saw “PHP Notice: Function _load_textdomain_just_in_time was called incorrectly” in your debug log after upgrading to WP 6.7, this version silences it.

What’s next#

The 4.3 line is in progress, with two themes already landing:

• Native Postgres support for tables backed by external SQL sources (we’re TableCrafter-ish; Gravity Tables itself stays Gravity-Forms-native)
• Real-time collaborative editing, Google-Docs-style cell ownership when multiple users edit the same table at once

Both are still behind feature flags in nightly builds. Watch the roadmap for ETAs.

Upgrade path#

Direct upgrade from any 4.1.x or 4.2.x is safe and reversible. No database migration. No setting changes required for the new features, they’re opt-in through new shortcode parameters and admin UI toggles.