How to Give Editors Edit Access and Viewers Read-Only Access in TableCrafter

Updated July 2026 • 7 min read • By Fahad Murtaza

The most common TableCrafter deployment pattern splits users into three tiers: administrators who see and control everything, editors who can modify data inline without wp-admin access, and viewers who read data but cannot change it. Setting this up correctly requires configuring both the table-level role settings and the shortcode attribute, and understanding what happens when a user has more than one role. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. TablePress has over 800,000 active installs on WordPress.org (WordPress.org, 2026).

What Is the Three-Tier Model?

Step 1: How Do I Table-Level Role Configuration?

Open your table in the TableCrafter admin and go to the Access & Permissions tab. Configure as follows:

• Allowed Viewer Roles: Check Subscriber, Editor, Administrator (and any custom roles that should see data).
• Allowed Editor Roles: Check Editor and Administrator only.
• Allowed Deleter Roles: Check Administrator only (or leave blank to disable deletion entirely on this table).

Save the table configuration.

Changes take effect immediately after saving. No cache flush or page refresh is required for the new configuration to apply to all shortcode instances of this table.

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

Step 2: How Do I The Shortcode Attribute Requirement?

Role configuration alone does not activate editing. The edit="true" shortcode attribute must also be present. This two-key design is intentional, it means you can place the same table on two different pages, one with editing enabled and one without, using the same table ID.

The shortcode for a table with editing enabled for appropriate roles:

[tablecrafter id="3" edit="true" filter="true" search="true"]

The shortcode for a read-only public view of the same table:

[tablecrafter id="3" filter="true" search="true"]

Both shortcodes point to table ID 3. The first renders editable cells to users in editor roles. The second renders read-only cells to everyone, regardless of role.

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.

What Each Role Sees?

The Subscriber Experience

A subscriber navigating to the page sees the table with all public columns populated. Each cell renders as static text. There are no hover states, no pencil icons, no click interactions on cells. The filter dropdowns and search box work normally. The subscriber can read and search but cannot modify anything. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block.

If you include export="true" in the shortcode and Subscriber is in the Allowed Viewer Roles list, subscribers will also see an Export button. To restrict export to editors only, remove Subscriber from a separate Allowed Exporter Roles field in the Access tab.

The Editor Experience

An editor navigating to the same page sees the same table. The difference appears on hover: hovering a cell highlights it with a subtle border. Clicking the cell opens an inline input. The input type matches the field, text fields become <input type="text">, dropdown fields become <select>, date fields become a datepicker. Pressing Enter or clicking away from the cell saves the change immediately via AJAX and writes it back to the data source (Gravity Forms entry, WooCommerce product, REST API endpoint, etc.).

Editors do not see a Delete row button unless Administrator-level delete is separately granted to the Editor role.

The Administrator Experience

Administrators see everything editors see, plus any admin-only columns configured on individual columns. They also see delete controls if deletion is enabled, and they receive a link to the raw Gravity Forms entry in the admin (if the data source is Gravity Forms) via a row action icon.

How Do Role Hierarchy and Conflict Resolution Work?

WordPress allows users to hold multiple roles simultaneously, a plugin like Members or User Role Editor makes this common. TableCrafter resolves conflicts by taking the most permissive role the user holds. If a user has both Subscriber and Editor roles assigned, they receive Editor-level access (viewing + editing). If they have Editor and Administrator, they receive Administrator-level access.

There is no way to reduce a user's access below their most permissive role without removing that role from the user account. TableCrafter does not support role exceptions at the individual-user level, for per-user overrides, use WordPress user meta and a custom filter hook.

How Does Testing the Role Split Work?

Use three browser sessions to verify all three tiers:

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

1. Incognito window A, log in as a Subscriber. Verify cells are static text. Attempt to manually POST to the TableCrafter AJAX save endpoint; confirm the response is a 403 with a permissions error message.
2. Incognito window B, log in as an Editor. Click a cell and confirm the inline input appears. Save a change. Confirm the updated value persists after a hard page refresh.
3. Regular window, logged in as Administrator. Confirm all columns are visible including any admin-only ones. Confirm delete controls appear if deletion is enabled.

What Is Common Misconfiguration: Forgetting edit="true"?

The single most frequent support question about this feature is: "I set Editor as an editor role but cells still aren't editable." In almost every case the shortcode is missing edit="true". Check the shortcode first before investigating role settings.

This setting persists across table rebuilds. If you change the data source later, you may need to revisit this step to remap columns from the new source to the existing table configuration.

This step applies universally to all instances of this table. If you have the same table embedded in multiple pages or posts, the setting takes effect on all of them simultaneously without any additional steps.

The column mapping you define here is stored as a JSON configuration in the WordPress database. You can export this configuration using the TableCrafter export tool and import it to another table or another site. This is useful when replicating a table layout across multiple pages or when migrating a table to a staging environment for testing before going live.

What Are the Next Steps?

With the three-tier role split working, the next logical step is restricting frontend editing further, for example, enabling editing only on a specific page or for a single session type. The guide on enabling frontend editing for specific roles only covers the Pro feature walkthrough in detail, including how to verify the editing UI appears and what a subscriber sees on the same page.

TableCrafter validates this configuration on save. If validation fails, the admin panel displays a specific error message identifying which field caused the problem. Correct the field value and save again without needing to restart the setup process.

TableCrafter re-fetches this data on each page load by default. If your data source updates infrequently and your site has significant traffic, enable the built-in caching option in the table's Performance tab. This stores the fetched data for a configurable number of minutes and serves it from WordPress transients, reducing API calls to the source and improving page load time for visitors.