Docs / Inline cell editing

Inline cell editing

Inline cell editing

Inline editing turns a published table into a live data surface — logged-in users with the right capability can double-click a cell, type a new value, and the change saves to the database. Useful for team rosters, status dashboards, or any table where multiple people maintain rows.

Turn it on for a table

  1. Open the table in the editor.
  2. Open the Pro features panel.
  3. Toggle Inline editing on.
  4. Pick a Minimum role — the lowest role that can edit cells. Choices: subscriber, contributor, author, editor, administrator.
  5. Save.

How editors use it

On the front end, a logged-in user with the required role sees a small edit indicator when they hover over a cell. Double-clicking opens an inline input. Tab or click outside to save, Esc to cancel.

Edits save immediately via REST. There's no "save" button — every successful edit hits the server right away.

Permissions model

Two checks gate each edit:

  • The user must have a role at or above the table's minimum role setting. Roles are compared by capability — "editor" means anyone with edit_others_posts, regardless of the role's display name. Custom roles work.
  • The user must also have WordPress's edit_post capability on the specific table post. Administrators always pass; for everyone else, this means the table must have been authored by them or their role grants per-post edit capability.

This per-post check is what prevents one team's editors from editing another team's tables on the same site.

What gets sanitized

The submitted text runs through wp_kses_post server-side — the same filter WordPress uses for the post editor. Allowed: paragraph-level HTML, <a>, basic formatting tags. Stripped: <script>, event handlers, iframe, etc.

Bounds

You can't grow the table by editing — only existing cells (within the saved row count and column count) accept edits. A stray write for row 999 returns a 400 error.

Race conditions

If two editors save the same cell at nearly the same moment, the later write wins. There's no etag/version check. For high-collaboration use cases, consider scoping inline-edit access to one editor per table.