Pro: Roles & Permissions

TableCrafter authorizes every privileged action through standard WordPress capability checks, and controls which columns reach the browser with the include and exclude shortcode attributes. This page documents the real permission model exactly as it ships in v3.5.6.

Capabilities Column Visibility Nonce Security REST Permissions Rate Limiting

ℹ️

TableCrafter does not implement a custom role manager or per-role column rules. Access is governed by WordPress core capabilities (manage_options, edit_posts, read), and column hiding is configured once per table via include/exclude. If you read a marketing line promising "role-based" column control, this page is the accurate engineering reference.

How authorization works

There is no plugin-specific role or capability to assign. Instead, each action TableCrafter performs is gated by a built-in WordPress capability that your existing roles already grant. The frontend table render is public (it outputs server-rendered HTML for visitors), while the AJAX proxy, exports, Elementor preview, and collaboration endpoints each enforce a capability before running.

Every privileged request is additionally protected by a nonce, so a valid capability is necessary but not sufficient. Both checks must pass.

Capability matrix

The table below maps each protected operation to the exact capability check enforced in the source. Capabilities are evaluated with WordPress core current_user_can().

Operation	Required capability	Nonce action
Save Airtable token (admin)	`manage_options`	`tc_proxy_nonce`
AJAX data proxy fetch	`edit_posts` OR `manage_options`	`tc_proxy_nonce`
Elementor live preview	`edit_posts` OR `manage_options`	`tc_proxy_nonce`
Export (CSV / XLSX / PDF)	`read`	`tc_export_nonce`
Collaboration REST routes	`read` (logged in)	`wp_rest`
Admin error / diagnostics helper	`manage_options`	n/a (render-side)

💡

In a default WordPress install: Administrators have manage_options; Editors and Authors have edit_posts; Subscribers (and everyone logged in) have read. To let a custom role use exports or collaboration, ensure that role has the read capability; to let it configure remote-data tables, grant edit_posts.

Column visibility with include and exclude

The closest thing to "who sees which columns" is column selection, and it is applied at the table level for all viewers. Use the include attribute to whitelist columns, or exclude to blacklist them. Both take a comma-separated list of source field keys. This is the correct mechanism for keeping sensitive columns (such as internal IDs or password hashes) out of the rendered output entirely.

Attribute	Type	Required	Description
source	URL	Required	Data source URL (JSON API, CSV, or Google Sheets). Sanitized with `esc_url_raw()`.
include	string	Optional	Comma-separated keys to show. Only these columns are rendered.
exclude	string	Optional	Comma-separated keys to hide. All other columns are rendered.
export	boolean	Optional	Show the export control. Defaults to `false`.
search	boolean	Optional	Enable the search box. Defaults to `false`.
filters	boolean	Optional	Enable column filters. Defaults to `true`.

Hiding sensitive columns: example

Drop sensitive fields before they ever reach the page. Because filtering happens during render, hidden keys are not present in the HTML, the search index, or exports.

// Show only safe columns to every visitor
[tablecrafter source="https://example.com/api/staff.json" include="name, title, department"]

// Or render everything except the sensitive keys
[tablecrafter source="https://example.com/api/staff.json" exclude="id, password_hash, ssn"]

⚠️

include/exclude are global per shortcode instance — they do not vary by the viewer's role. If different audiences must see different columns, publish two shortcodes on capability-gated pages (for example, wrap the fuller table in a template check) rather than expecting the attributes to branch by role.

Configuring columns in the admin builder

The table builder exposes the same controls without writing the shortcode by hand. Go to WP Admin → TableCrafter, open a table, and use the two fields:

Include Columns — "Comma-separated list of keys to show" (placeholder name, price, stock).
Exclude Columns — "Comma-separated list of keys to hide" (placeholder id, password_hash).

These map to data-include and data-exclude on the rendered <div class="tablecrafter-container"> wrapper, which the frontend script reads to build the visible column set.

Restricting export and collaboration

Exports run through the export handler and require the read capability plus a valid tc_export_nonce; the same handler produces genuine CSV, XLSX, and PDF output. Real-time collaboration registers REST routes under tablecrafter/v1 (/collaboration/join, /leave, /broadcast, /sync), each guarded by check_collaboration_permission(), which requires the user to be logged in, present a valid wp_rest nonce, and hold read.

To disable collaboration entirely, leave the tablecrafter_collaboration_enabled option off — the localized can_collaborate flag then reports false.
To prevent anonymous use, note that collaboration always requires a logged-in user; visitors who are not signed in fail the permission callback.

Rate limiting and the data proxy

The AJAX proxy that fetches remote data on behalf of editors is throttled to prevent abuse, independent of role. The limit is 30 requests per 60-second window per user; exceeding it returns HTTP 429. Combined with SSRF protection in the security layer, this keeps the proxy from being turned into an open relay even by an authorized account.

ℹ️

When a fetch fails, admins (manage_options) see a detailed diagnostic helper, while non-admin visitors see a graceful, generic message. This is a deliberate disclosure boundary — error internals are never shown to ordinary users.

Hardening checklist

Use include/exclude to drop any column you would not want a logged-out visitor to read; do not rely on CSS to hide it.
Confirm that custom roles which need exports actually have read, and that table-editing roles have edit_posts.
Keep the data source itself authenticated where possible; TableCrafter authorizes the WordPress request, not the upstream API.
Leave nonces and rate limiting at defaults unless you have a specific reason to change them.

Next, see shortcode-attributes.html for the full attribute reference, and pro-export.html for how the capability-gated CSV, XLSX, and PDF export pipeline is configured.