Setup
Deactivate, uninstall, and your data
Deactivating stops governance. Uninstalling can also remove the data, but only if you asked for that in advance.
- Install & activate
- 4 min read
Deactivating
Deactivation stops the control plane and cleans up scheduled workflow hooks. Your agents, permissions, approvals, sessions, and audit chain stay in the database exactly as they were, so reactivating resumes where you left off.
While the plugin is inactive, requests are no longer governed — but the Application Password still authenticates, and the underlying WordPress user still has whatever capabilities it has. If you are deactivating because something is wrong, revoke the connection first.
Uninstalling
Data removal on uninstall is opt-in. By default, deleting the plugin leaves your governance data in place, because the audit trail is frequently the most valuable thing on the site and deleting it as a side effect of removing a plugin would be indefensible.
If you do opt in, uninstall removes the plugin’s tables and options, including multisite data across the network. It does not delete WordPress users, content, or Application Passwords — those are yours and WordPress owns them.
Why removal cannot leave a privilege behind
RuleFence only ever narrows what is possible. It cannot grant an agent anything WordPress does not already allow, so removing it cannot leave behind a privilege that should not exist. What removal does leave behind is the WordPress user you created for the agent, with whatever role you gave it.
That is the thing to clean up. Removing the boundary is only safe if you also remove or restrict the account it was drawn around.
Clean removal checklist
- Revoke each agent’s connection, which invalidates its credentials and terminates its sessions.
- Export the audit evidence if you may need it later. This is the point of no return.
- Decide whether to opt in to data removal.
- Deactivate and delete the plugin.
- Delete or demote the WordPress users the agents connected as.
Install & activate
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.