Inline Edit Validation Rules

By Fahad Murtaza • Updated July 2026

Attach validation rules to individual columns so that bad data never reaches your Gravity Forms entries. When a user attempts to save an inline-edited cell that fails a rule, the save is blocked and a descriptive error message appears directly below the input.

Overview

TableCrafter's inline editing lets authorized users click any editable cell in a frontend table and update the underlying Gravity Forms entry without leaving the page. Validation rules extend that workflow by letting you define what constitutes a valid value for each column before the save reaches the server.

Validation is configured per column in the admin table builder and stored alongside the rest of the table configuration. At render time, the rules are embedded in the JavaScript configuration for the table (Pro license check gates this output). When a user commits an edit, the rules are evaluated client-side to give immediate feedback, and the save is also validated server-side before the Gravity Forms entry is updated.

Rules work across all three input types that the inline editor supports:

• Text inputs (single-line text and number fields)
• Textarea inputs (paragraph / long-text fields)
• Dropdown selects (choice fields, including Gravity Forms dropdown and radio fields mapped to a select)

Enabling and Configuring Rules Per Column

Validation rules are set in the field configuration modal inside the TableCrafter admin builder. Open WordPress Admin → TableCrafter, open or create a table, then locate the column you want to constrain in the drag-and-drop column list.

1. Click the gear icon on the column row to open the field configuration modal.
2. Make sure Allow Inline Editing is toggled on for that column. The Validation tab only appears when inline editing is enabled for the column.
3. Click the Validation tab inside the modal.
4. Click Add Rule to add one or more rules to the column.
5. For each rule, choose a Rule Type from the dropdown and fill in the corresponding value and, for regex, a custom error message.
6. Click Save Column to apply. The rules are saved as part of the table configuration.

You can add multiple rules to a single column. All rules are evaluated on each save attempt; all failures are reported simultaneously so the user sees every problem at once rather than one at a time.

Rule Types Reference

Five rule types are available. Each is evaluated independently; a column can have any combination of them.

How Save Blocking Works

When a user commits an inline edit (via the Enter key, the Tab key, or clicking away from the cell), TableCrafter runs the following sequence:

1. Client-side validation — The rules embedded in the table's JS config are evaluated against the current input value immediately, before any network request is made. If any rule fails, the save is aborted and the error message(s) are rendered below the input. No AJAX request is issued.
2. Server-side validation — If client-side passes, the value is sent to the TableCrafter AJAX save endpoint. The server re-evaluates all rules from the stored table configuration (never from the request payload). If server-side validation fails for any reason (e.g., the JS was bypassed), the save is rejected and an error response is returned to the frontend, which surfaces it as an inline error.
3. Gravity Forms entry update — Only after both layers pass does TableCrafter call the Gravity Forms API to update the entry field value.

The cell remains in an editable state after a validation failure, so the user can correct the value and try again without having to re-click the cell. The error message clears automatically when the user modifies the input.

Error Message UX

Error messages appear inline, directly below the input that failed validation. They are not modal popups, toast notifications, or browser alert() dialogs. This keeps the user's focus on the specific cell that needs correction.

The error container is a <div> with the class .gt-validation-error injected below the input element inside the active cell. You can target this class in your theme's CSS to adjust color, font size, or spacing to match your site design.

Default behavior:

• Error text is displayed in a red/destructive tone using the table's existing color scheme.
• If multiple rules fail simultaneously, each error is listed as a separate line.
• The error clears as soon as the user begins typing a corrected value.
• If the user presses Escape to cancel the edit, errors are discarded with the edit.

For regex rules, the error message shown is the custom message you provide in the admin builder, not the raw pattern. Always write your custom message in plain language that makes sense to the end user. For example, instead of "Value does not match ^[A-Z]{2}\d{6}$", write "Enter a load reference in the format AB123456."

Admin Configuration and JSON Structure

The following illustrates what a column configuration looks like after adding validation rules in the admin builder, and how that configuration is stored in the table's JSON config object.

Example: "Gross Weight (lbs)" column for a load-tracking table

In the field configuration modal, the Validation tab would have two rules configured:

• Rule type: required
• Rule type: min_value, Value: 1
• Rule type: max_value, Value: 80000

These rules are serialized into the table configuration stored in the WordPress database. The relevant portion of the stored JSON structure looks like this:

// Excerpt from the stored table column configuration
{
  "field_id": 14,
  "label": "Gross Weight (lbs)",
  "inline_edit": true,
  "validation_rules": [
    {
      "type": "required"
    },
    {
      "type": "min_value",
      "value": 1
    },
    {
      "type": "max_value",
      "value": 80000
    }
  ]
}

A column using a regex rule (for example, enforcing a structured load reference code) would look like this:

{
  "field_id": 7,
  "label": "Load Reference",
  "inline_edit": true,
  "validation_rules": [
    {
      "type": "required"
    },
    {
      "type": "min_length",
      "value": 8
    },
    {
      "type": "max_length",
      "value": 8
    },
    {
      "type": "regex",
      "pattern": "^[A-Z]{2}\\d{6}$",
      "message": "Enter a load reference in the format AB123456."
    }
  ]
}

Pro Security Enforcement

Validation rules ship with a two-layer enforcement model designed to ensure that free-tier users and unauthenticated visitors cannot receive or exploit validation configuration, even via manual payload manipulation.

Layer 1: Render-time strip

When TableCrafter outputs the table's JavaScript configuration to the page, validation rules are included in that output only if the current site has an active Pro license. Free-tier sites receive a JS config with validation_rules omitted entirely from every column. There is no client-side validation for free tables because the rules are never present in the page source.

Layer 2: Persist-time strip

When the inline-edit save AJAX endpoint receives a request, it loads the validation rules exclusively from the server-side stored table configuration. It does not read, trust, or use any rule data that might be present in the request payload. Even if a free-tier user hand-crafted a POST body that included fabricated validation_rules, the server would ignore them entirely.

Combined, these two layers mean:

• Free users never see validation rule configuration in the admin builder (the Validation tab is hidden).
• Free users never receive validation rule data in the frontend JS config.
• No crafted payload can introduce validation behavior on a free-tier site.
• Pro validation is enforced server-side on every save regardless of client-side state.