Visibility Overview
Visibility controls whether the plugin enqueues the public widget for Everyone, selected WordPress roles, or selected individual users.
Visibility decides whether WordPress adds the frontend widget assets for the current visitor. Everyone includes anonymous traffic; Roles and Users require a logged-in match. This is useful for staged rollouts and internal assistants, but it is a presentation/access gate for the widget—not authentication for every public REST route or authorization for sensitive tool data.
Start with the smallest safe step: open access and note the current mode. Do not consider the task finished before you purge any page cache after an access change; this is where the configuration is tested in the context that truly consumes it.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Use restricted access for setup, staging, internal assistants, or content intended only for authenticated groups.
Use this feature in the following situations:
- You are keeping a new assistant available only to administrators or a pilot group.
- You are publishing the widget to all anonymous and logged-in visitors after approval.
- You are diagnosing why one login sees the launcher and another visitor does not.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Open Access and note the current mode.
- Choose Everyone, Roles, or Users.
- For a restricted mode, select the exact roles or accounts.
- Save.
- Test with a permitted signed-in session, a nonpermitted session, and a signed-out private browser.
- Confirm both launcher presence and absence on uncached pages.
- Purge any page cache after an access change.
Fields, controls, and important values
Section titled “Fields, controls, and important values”Visibility controls decide who receives the chat interface; they do not change the active assistant’s knowledge or response style. Narrow access can be useful for an internal or staged assistant, but it is only a display and enqueue decision. Any tool or returned data still needs its own authorization because hiding the widget from other users is not a security boundary.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| Everyone | Allows WordPress to enqueue the public widget for both signed-out visitors and logged-in users. | Choose this when signed-out visitors and logged-in users should both receive the widget. It maximizes reach but does not authorize sensitive answers, so every data-returning tool must still enforce its own access rules. |
| Roles | Requires a logged-in WordPress account with at least one role selected in the access settings. | “Roles” limits exposure according to the behavior described beside it. Verify the boundary in separate sessions and avoid assuming that hiding a widget or schema protects the data behind it. |
| Users | Requires a logged-in WordPress account whose exact user ID is in the saved selection. | Select exact WordPress accounts for a small internal or staged audience. This narrows who sees chat, while the AI’s knowledge and wording remain unchanged for those who are allowed in. |
| Role selection | Stores the WordPress role keys that are accepted when Roles mode is active. | Pick the roles whose members genuinely need the assistant and test accounts with single and multiple roles. The role decides widget availability; it does not automatically limit what an enabled tool can return. |
| User selection | Stores exact allowed user IDs. The screen loads at most 200 accounts ordered by display name. | The choice in “User selection” decides where this feature is available. It may affect who can ask the AI or which profile sees a tool, but it does not make the resulting answer safer unless the underlying operation also checks access. |
| Save Changes | Stores the selected mode and audience. Cached public pages may need purging before every visitor receives the new enqueue decision. | “Save Changes” commits the values or advances the workflow; it is not the final proof that everything works. Follow it with the page’s success check, especially when OpenAI, Meta, email, knowledge indexing, or frontend caching is involved. |
How to confirm it is working
Section titled “How to confirm it is working”Use a separate test session to confirm Visibility Overview. This keeps existing login, browser storage, and response history from hiding the change, and it shows whether the result reaches the complete workflow rather than stopping at WordPress storage.
Practical example
Section titled “Practical example”During setup, restrict the widget to Administrators; after approval, change to Everyone.
Recommended practice
Section titled “Recommended practice”- Change one part of Visibility Overview at a time and keep a short record of the previous value and test result.
- Verify the saved result in the screen, visitor session, or connected service that actually consumes the setting.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| Visibility Overview is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
| A change on Visibility Overview does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
Screen reference
Section titled “Screen reference”- Capture
- Show Settings → Access with Roles selected and only a fictional test role checked.
- Show
- Everyone/Roles/Users modes, role list, Save
- Viewport
- Desktop, 1440 × 900
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text