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?

TableCrafter separates two concerns that many role plugins conflate: who can see the table, and who can change values inside it. Viewing access is controlled by the allowed_user_roles shortcode attribute, a comma-separated list of WordPress role slugs. If the attribute is empty, any logged-in user can view the table. Editing access is controlled by the user_roles_can_edit setting stored in the table's configuration record in the WordPress database. These two settings operate independently, so you can configure a table where Subscribers see all rows in read-only mode, Editors see the same rows with inline edit affordances, and Administrators also see columns that are hidden from the other two tiers via per-column role visibility rules. Both checks are enforced server-side on every request, not only in the browser. The three tiers described below are the most common starting point for this type of deployment.

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.

The Allowed Viewer Roles list maps directly to the allowed_user_roles shortcode attribute. When TableCrafter's pagination REST endpoint or any AJAX data handler receives a request, it checks whether the current user holds at least one role on that list before returning any data. Users who do not qualify receive a permissions error and see no table content, including no column headers. The Allowed Editor Roles list corresponds to the user_roles_can_edit setting stored in the table's configuration record. This setting is evaluated independently of the viewer list: a user must satisfy both checks to receive editing affordances. Because these checks happen server-side on every request, placing the shortcode on a publicly accessible page does not bypass the role restriction, and removing a role from either list takes effect immediately for all pages hosting the shortcode.

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.

The admin-only column visibility is controlled through per-column role visibility rules, a Pro feature stored as column_role_visibility in the table configuration. Each column's allowed roles are stored as an array of WordPress role slugs. When the server builds the data response, the TC_Column_Visibility class checks the logged-in user's roles against each column's allowed list and removes any columns the user is not permitted to see before returning data to the browser. This enforcement happens at the data layer: restricted column values are never sent to the client, so there is no risk of a browser-side workaround exposing sensitive fields. This matters for tables that mix standard data with fields such as internal cost margins, HR notes, or management ratings that live in the same Gravity Forms source as the public-facing data.

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.

A secondary misconfiguration that produces the same symptom is running the free tier of TableCrafter and expecting inline editing to appear. The edit="true" shortcode attribute is a Pro feature. On the free tier, the attribute is silently ignored and all tables render as read-only regardless of role configuration. Verify your license is active under TableCrafter → License before investigating shortcode attributes or role settings. If the license page shows no active plan, the site is running the free version from WordPress.org.

A third scenario is a caching plugin delivering a stale page that was rendered before the edit="true" attribute was added to the shortcode. If cells remain non-editable immediately after adding the attribute, flush the page cache and reload. NitroPack, WP Rocket, and LiteSpeed Cache each provide a cache-purge action in the WordPress admin toolbar. After flushing, confirm the edit attribute appears in the shortcode on the page and that the correct table ID is referenced.

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.

If you also need to control which columns are visible to each role, the per-column role visibility feature in the Pro tier lets you configure each column independently. A Salary column could be restricted to Administrators while all other columns remain visible to every viewer role. Column visibility is enforced server-side through the TC_Column_Visibility class, which strips excluded columns from the data payload before it reaches the browser, ensuring restricted field values never appear in the network response for lower-tier users.

For tables where you want to notify staff when a specific value changes to a meaningful threshold, such as when a total exceeds a budget cap or a count drops below a minimum, the threshold alert feature pairs naturally with this setup. See the guide on sending an alert when a table field exceeds a threshold for the full configuration walkthrough, including how to combine alerts with role-restricted editing so only trusted roles can trigger the monitored changes.

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.