Skip to content

Reset, Deactivation, and Removal Behavior

Deactivation removes copied compiled widget assets under the SmartSite uploads asset directory. The audited plugin has no uninstall hook that deletes its options, custom log table, uploaded knowledge files, or remote OpenAI resources.

WordPress deactivation stops the plugin and removes only the copied compiled asset directory. Assistant profiles, credentials, knowledge mappings/files, design/access/security options, conversation logs, and remote OpenAI resources are not automatically erased. Permanent removal is therefore a multi-location data operation, not simply clicking Delete on the plugin row.

Start with the smallest safe step: back up and inventory all smartsite data before a change. Do not consider the task finished before you delete the plugin only after the approved evidence and rollback window; this is where the configuration is tested in the context that truly consumes it.

Use this information to plan a reversible disable or an owner-approved full data removal.

Use this feature in the following situations:

  • You need to disable the widget temporarily while preserving a reversible configuration.
  • You are planning a complete removal and need an inventory of what survives deactivation/deletion.
  • You are responding to a data-erasure or service-termination requirement across local and remote systems.
WordPress locationWordPress Dashboard → Plugins → Installed Plugins → SmartSite Assistant
  • SmartSite Assistant is installed and activated.
  • You are signed in with an account that can manage WordPress options.
  1. Back up and inventory all SmartSite data before a change.
  2. If temporarily disabling, deactivate the plugin and confirm the public widget disappears.
  3. Reactivate and verify compiled assets are copied back and settings remain.
  4. For permanent removal, obtain owner/privacy approval and define local and remote deletion scope.
  5. Remove data through supported admin controls where available, such as knowledge files and logs.
  6. Have a qualified administrator/developer verify remaining WordPress options, the smartsite_logs table, uploads, transients, vector store/files, and vendor data.
  7. Delete the plugin only after the approved evidence and rollback window.

Deactivation and removal choices affect code and copied assets differently from saved settings, logs, uploads, and remote provider data. They do not improve answers; they determine what survives a maintenance action and what can be restored later. Understanding the scope prevents an incomplete cleanup or an accidental loss of the material needed to reproduce the assistant.

Fields, controls, and important values
Field, control, or statusWhat SmartSite Assistant does with itHow to use it and why it matters
Deactivate Removes copied app assets from uploads/smartsite-assistant/assets; preserves configuration and data. “Deactivate” belongs to upkeep rather than response writing: Removes copied app assets from uploads/smartsite-assistant/assets; preserves configuration and data. Understanding its scope prevents unnecessary model or instruction changes when the real issue is deployment, storage, cleanup, or recovery.
Delete plugin WordPress removes plugin files, but no plugin uninstall cleanup is registered. “Delete plugin” is an operational or destructive action rather than an answer-quality control. Use it under the site’s retention or change process, then verify that remaining knowledge, logs, and external data match the intended result.
Knowledge file Remove Supported control that deletes local and OpenAI file resources for that item. Removing a knowledge document should be treated as both a WordPress and remote-data operation. Confirm the intended file disappears from the vector-store workflow, then ask a fresh question so old conversation context does not mask the removal.
Analytics cleanup Deletes selected/aged local log rows only. Choose a retention cutoff that matches the site’s policy and preserve only the sanitized evidence still needed. Cleanup deletes local conversation records; it does not retract content already sent to OpenAI or an external tool.

Use a separate test session to confirm Reset, Deactivation, and Removal Behavior. 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.

Deactivate during incident containment, then reactivate after fixing credentials without expecting assistant profiles to be reset.

  • Change one part of Reset, Deactivation, and Removal Behavior 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.
Common problems and focused checks
ProblemWhat to check and what to do next
Reset, Deactivation, and Removal Behavior is missing or does not match this guide. Confirm the plugin is active and the account can manage WordPress options. Preserve logs and configuration evidence before changing files, caches, update state, or stored data.
A change on Reset, Deactivation, and Removal Behavior does not produce the expected result. Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Preserve logs and configuration evidence before changing files, caches, update state, or stored data.
Reset, Deactivation, and Removal Behavior
Capture
Show the Installed Plugins row with Deactivate visible and an annotation stating “configuration remains”; no destructive action in progress.
Show
Plugin name/version, Deactivate, annotation about retained data
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