How to Show Different Table Views to Logged-In vs Guest Users in WordPress

Updated July 2026 • 7 min read • By Fahad Murtaza

Many WordPress sites need to show table data publicly, for SEO, for prospects, for general reference, while giving authenticated users a richer experience with more columns, editing capabilities, or export controls. TableCrafter supports two approaches to this guest-vs.-logged-in split: a role-settings approach that works entirely within the plugin configuration, and a template conditional approach using WordPress's is_user_logged_in() function with two separate shortcodes. This guide covers both. 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. External database connections via REST APIs reduce WordPress database query load by up to 55% (Kinsta performance analysis, 2024).

What Is Approach 1: TableCrafter Role Settings (Recommended for Most Cases)?

The simplest implementation uses a single shortcode and TableCrafter's built-in role settings to deliver different experiences based on authentication state. TableCrafter evaluates the allowed_user_roles configuration on every request through its canCurrentUserViewTable() method, which compares the current user's WordPress role array against the configured list. Administrators always bypass the check and can view any table. For unauthenticated visitors, TableCrafter checks whether the configured role list is empty (meaning all can view) or explicitly includes a guest-equivalent setting. Role-based column visibility lets you mark specific columns as hidden for certain roles without creating a separate table configuration, so a guest might see product name and price while a logged-in subscriber also sees stock level and SKU. This approach handles the majority of guest-vs-logged-in requirements without any PHP and works correctly with TableCrafter's AJAX data loading, meaning the role check runs server-side on the AJAX request rather than relying on client-side JavaScript state.

Configuration Steps

Open the table in TableCrafter → Tables and go to Access & Permissions:

1. In Allowed Viewer Roles, check the Guests (not logged in) option and every logged-in role you want to have access (Subscriber, Editor, Administrator, etc.).
2. In Allowed Editor Roles, check only the logged-in roles that should edit, do not check Guest.
3. In the Columns tab, mark any columns that should be hidden from guests as not visible to the Guest role.

Deploy the shortcode on the page:

[tablecrafter id="6" filter="true" search="true" edit="true" export="true"]

Guests visiting the page see a filtered, searchable read-only table with only public columns. Logged-in Editors see the same table with additional columns and clickable editable cells. Administrators see everything including admin-only columns.

Limitations of This Approach

The role settings approach works well when the guest and logged-in views share the same data source and column structure, so guests see a subset of what logged-in users see. There are several scenarios where it falls short. First, column-level role visibility (hiding specific columns for specific roles) is a Pro feature. On the free tier, you can restrict table access entirely by role, but you cannot hide individual columns per role. Second, if you need a fundamentally different table layout for guests versus logged-in users, such as a different data source, a different column order, different default sort, or different row-level filters, Approach 2 gives you complete control. Third, for External DB source tables, allowing guest access requires enabling the external_db_public_render setting in addition to including guests in the allowed viewer roles. This setting bypasses the gravity_tables_view_external capability check for unauthenticated visitors; without it, guest requests are blocked even if the role list would otherwise permit them. Finally, the single-table approach cannot give guests and logged-in users entirely different interactive experiences (different toolbars, search vs. no search) without Approach 2.

What Is Approach 2: Two Shortcodes with a Template Conditional?

This approach creates two distinct TableCrafter table configurations and uses a WordPress PHP conditional to display the appropriate one based on authentication state. The two tables can have completely different settings, column sets, and even different data sources. A public product catalog table might pull from a CSV or Google Sheet while the logged-in member version pulls from a live Gravity Forms entry source with inline editing enabled. The conditional wraps both shortcodes in a server-side is_user_logged_in() check, meaning only one shortcode is processed per request: TableCrafter does not render the other table at all, and its data is not fetched. This is an important distinction from client-side show/hide CSS toggling, where both tables would be rendered in the HTML and the data for both would be fetched. The PHP conditional approach ensures the guest version's data is never sent in the response when a logged-in user loads the page, and vice versa.

Step 1: Create Two Table Configurations

In TableCrafter → Tables, create two tables. Both can connect to the same underlying data source, but their column configurations and access settings will differ. The guest table should be built for search engine crawlability and fast load: fewer columns, no edit controls, no export, and no login requirement. The logged-in table should include the full column set including any sensitive or internal fields, with inline editing and export enabled, and with the guest role excluded from allowed_user_roles so that TableCrafter's server-side access check blocks any unauthenticated direct-access attempts even if the PHP conditional is somehow bypassed.

• Table ID 10, Public View: Five public-safe columns, no edit, no export, guest access allowed. This is the SEO-visible table.
• Table ID 11, Member View: Eight columns including sensitive fields, edit enabled, export enabled, guest NOT in Allowed Viewer Roles, Subscriber + Editor + Administrator in Allowed Viewer Roles.

Note the numeric table IDs shown in the admin URL when editing each table. These go into the shortcodes in Step 2.

Step 2: Add the Conditional Template

In your WordPress theme's page template, or in a Custom HTML widget on the target page, use the following PHP template tag pattern:

<?php if ( is_user_logged_in() ) : ?>
  [tablecrafter id="11" edit="true" filter="true" search="true" export="true"]
<?php else : ?>
  [tablecrafter id="10" filter="true" search="true"]
<?php endif; ?>

Because shortcodes inside PHP template files are not automatically processed, call do_shortcode() around each:

<?php if ( is_user_logged_in() ) : ?>
  <?php echo do_shortcode( '[tablecrafter id="11" edit="true" filter="true" search="true" export="true"]' ); ?>
<?php else : ?>
  <?php echo do_shortcode( '[tablecrafter id="10" filter="true" search="true"]' ); ?>
<?php endif; ?>

If you are using Elementor or a similar page builder that does not provide direct PHP access, use a shortcode-wrapper plugin or the Elementor PHP widget to execute this conditional. An alternative is a shortcode macro plugin that wraps the conditional in its own shortcode:

[if_logged_in]
  [tablecrafter id="11" edit="true" filter="true" search="true" export="true"]
[/if_logged_in]
[if_logged_out]
  [tablecrafter id="10" filter="true" search="true"]
[/if_logged_out]

How Does Caching Considerations Work?

Full-page caching (WP Rocket, NitroPack, WP Super Cache) caches the rendered HTML. If a guest loads a page and that HTML is cached, a logged-in user visiting next might see the guest version from cache.

Mitigate this with two strategies:

1. Cache exclusion by cookie: Configure your caching plugin to serve uncached pages to users with the WordPress authentication cookie (wordpress_logged_in_*). Most major caching plugins support this by default, but verify it is active.
2. Fragment caching via AJAX: Because TableCrafter loads table data via AJAX after page load, the page HTML itself can be cached. The AJAX call runs client-side and is authenticated, so the correct role-filtered data is always fetched regardless of which HTML page was served from cache. This is the default TableCrafter behavior and is the primary reason role filtering is AJAX-based rather than server-rendered.

How Does SEO Implications of the Guest View Work?

Googlebot crawls as an unauthenticated user. If you enable guest access in the table's Allowed Viewer Roles (or use the PHP conditional approach with a guest shortcode), Googlebot fetches and indexes the table data rendered to guests. TableCrafter loads table data via AJAX, and Googlebot does execute JavaScript, but indexing of dynamically loaded content is not guaranteed at the same speed as static HTML. For tables where search visibility is a priority (product catalogs, reference tables, event listings), consider whether the data should be included in static HTML at render time. If the public table data is time-sensitive or frequently updated, set a reasonable dateModified value in the page's structured data so Googlebot re-crawls it at appropriate intervals. If the table contains private data, ensure Guest is not in Allowed Viewer Roles and protect the page with a login gate. A page that requires authentication will not be crawled meaningfully by Googlebot, but confirm this with Google Search Console rather than assuming it: test the URL with the Inspect tool to see what Googlebot renders.

How Does Testing the Conditional Work?

Test both states explicitly rather than assuming the conditional works. Each step should be treated as a distinct test because issues often manifest only in one direction.

1. In a private/incognito window (unauthenticated), navigate to the page. Confirm the public table appears with the correct columns and no edit controls. Open the browser console and verify there are no JavaScript errors. Also confirm that the member table's data is not present anywhere in the page source (right-click View Source) — it should not be, because the PHP conditional prevents it from rendering.
2. Log in as a Subscriber-role user in the same window. Confirm the member table appears with all expected columns and any editing or export controls. If the public table still appears instead, check that your caching plugin is configured to serve uncached pages to authenticated users. Most caching plugins exclude users who have the WordPress authentication cookie from the cache by default, but verify this is active.
3. Log out again. Confirm the public table returns and edit controls are absent. If they persist, your cache is serving the authenticated HTML to logged-out users.

What Are the Next Steps?

With guest vs. logged-in views working, there are several natural next extensions. The most common is pre-filtering a table via URL parameters while also enforcing role restrictions. The guide on combining URL parameter filters with role-restricted tables shows how to pass a ?status=Pending URL parameter to a table that is also locked to logged-in editors, a useful pattern for shared deep links in team workflows.

A second extension is current-user filtering: showing each logged-in user only rows they submitted or that belong to them. This requires enabling the user filter in TableCrafter's filter configuration and works independently of which approach (role settings or conditional shortcode) you use for the guest/member split. The two features compose cleanly: a logged-in subscriber can see only their own rows while a guest sees an aggregate public view of all rows with sensitive columns hidden.

For External DB source tables where you want guests to view data without WordPress authentication, enable the external_db_public_render setting in the table's Advanced options. This flag bypasses the gravity_tables_view_external capability check for unauthenticated visitors and is the correct route to public External DB tables without granting the capability to the public WordPress role.