bapakrob

Viva ChatGPT. Now I only need someone to confirm this method.

Good — here’s a more detailed, step-by-step walk-through (based on the latest publicly available Tablesome docs) for how to set up Tablesome Pro so that each WordPress user only sees and can edit their own row in a table. Step-by-Step: Setting Up Tablesome Pro for User-Specific Frontend Editing

1. Prepare Your Table
   • Go to Tablesome → Create New Table in your WP admin.
   • Either import your spreadsheet (CSV / XLSX), or manually create the columns and rows.
   • Make sure you have a “hidden” column in the table for “Created by” (or “Created_By” / “Updated_By”) — Tablesome uses that to track which user owns a row.
   • If you’re importing, your CSV/XLSX should have a column for the WP user ID (or something that you can map to who “owns” that row). (If you only have email, you’ll need to convert that into a user ID somehow — e.g. by exporting WP users, matching email to ID, and updating your sheet.)
2. Set Up the “On Table Load → Filter Table” Workflow
   • In your table editor, go to the Workflows section.
   • Create a Trigger: “On Table Load” (this runs when the table is being loaded on the frontend).
   • Add an Action: “Filter Table” when the trigger fires.
   • Configure the filter:
     • In the “where” (condition) part, choose your hidden “Created by” (or “Updated by”) column.
     • Set it to equal “Currently Logged-in User” (this is a smart field that Tablesome provides).
   • Save the workflow.
   Result: Now, when a user visits the page with the table, only the rows that they “own” (i.e. where “Created by” = their WP user) will be shown.
3. Enable Frontend Editing
   • Still in the table editor, go to the Frontend Editing tab / settings.
   • Turn on “Enable Frontend Editing” for that table.
   • Choose which User Roles are allowed to edit. You probably want to allow “Subscriber” (or whatever role your users are) if they need to edit their row.
   • Turn on “Allow Users to Edit Only Their Own Records.” This ensures that even if someone tries to access the table, they can’t edit rows not assigned to them.
   • Next, select which columns should be editable from the frontend. For example, you might leave the “user ID / created_by” hidden field locked, and only allow them to edit other data columns.
   • Optionally, choose whether they can delete their own rows from the front end.
   • Save these settings.
4. Embed the Table on a Frontend Page
   • Once your table and workflows are configured, copy the shortcode for that table.
   • Create or edit a WordPress page / post (or a Divi module) and insert that shortcode where you want the table to appear.
   • Make sure that page is only accessible to logged-in users, or at least to the roles you configured (so that anonymous visitors don’t see anything).
5. Test as a Normal User
   • Log in as a test user (one of your 100 users).
   • Visit the page with the table.
   • Confirm:
     • The user only sees their own row.
     • The user can edit the allowed columns.
     • Saving works.
     • (If allowed) the user can delete their row.
6. Extra: Allow Adding New Rows (Optional)
   • If you want users to be able to add new rows from the frontend (not just edit), there’s a Tablesome Pro feature for that: “Allow Users to Add Records” in the frontend editor settings.
   • Enable it, pick which roles can add, and decide whether they can see / edit only their own newly added rows via the same “Filter Table on Load” workflow.

Important Considerations & Caveats

• The “Filter Table” + “On Table Load” trick is key: without filtering, users will see all rows, even if you limit edit permissions. The filter ensures they only see their own data.
• Make sure your “Created by” or “Updated by” column is properly populated when you import: if that’s empty or wrong, the filter won’t work correctly.
• Frontend editing only works in Tablesome Pro — you need the Pro license.
• Be careful with large tables: some users report performance issues when tables are very large.
• Security: since users can edit from the frontend, double-check that only non-sensitive fields are editable, or validate input properly.

Hi Jarno, Thanks! I followed these steps yesterday, to no succes. This time it worked. Probably over heated 🙂

Hi Jyoti,
I have currently disabled it on the home page. For the time being I’m using another plugin.
I’ve set up this page https://schoolforinformation.org/test/

Hi Serge,
I see, just curious – can you tell me why you recommend to avoid this?