PANELKIND 1.7.2 · DOCUMENTATION · 5 NOVEMBER 2026

Drafts, publication, preview and recovery

Configure and publish

  1. Open PanelKind and edit the relevant View, role policy, widget, guide or styling.
  2. Save the shared draft. Clients continue using the published configuration.
  3. Preview a role or user using the saved draft; inspect expected pages and denied destinations.
  4. Review publication impact, add a note if useful, and publish.
  5. Open the affected WordPress workspace to confirm the published result.

Unsaved edits can be saved to the shared draft when starting preview, without publishing. Drafts are shared between authorised managers, not private per-person workspaces. Tokens and active-version checks reject stale saves/publications with a conflict. Reload and reconcile rather than overwrite another manager's changes.

Saving, publication, import and restore are checked against the current license and published baseline. A paid draft cannot be published on Free if it introduces inadmissible capacity or paid settings. Role definition changes and license actions take effect immediately, outside this workflow.

Actual WordPress preview

Agency owners can preview a role or user using a saved-draft or published snapshot, with an optional View override. The preview opens actual admin screens: lists, editor, media, plugin pages, dashboards, guides and sections. The subject cannot have native capabilities beyond the owner. A View override changes presentation while keeping subject permissions; protected owner users retain their full administration.

User preview uses that user's identity, content ownership, assignments, individual exceptions and checklist state. Role preview temporarily applies that role's capabilities to the current account, including roles with no members; content ownership follows the current account, with the owner's individual workspace exceptions/checklist history excluded. Use a user preview for a person's actual content view.

Preview is browse-only: native POST forms, destructive GET actions, REST saves and non-read AJAX writes are blocked, and a database write guard covers preview requests. Add New and Quick Draft may create temporary auto-drafts; these are tracked and removed on exit or scheduled expiry cleanup. Controls and checklist saves are disabled. Original login cookies and persistent role assignments are not replaced.

One preview is active across this site's admin tabs in the browser session. It expires after one hour. Exit preview returns to PanelKind; Change preview reopens the picker. Denied/expired pages also have exit links. Exit does not depend on target permissions or nonce freshness; opening PanelKind directly also exits.

Third-party callbacks execute under the preview identity. Screens requiring write requests to render may fail. Filesystem writes, outbound services and external persistent-cache side effects are outside the database guard. Preview is not a complete isolated clone of the site.

History and recovery

Published revisions are retained within a configurable 5–50 range, default 20. Configuration activity is recorded separately, with 100–10,000 audit entries retained, default 1,000. This is configuration activity history, not comprehensive logging of every WordPress user action.

Restoring a revision stages its configuration as a draft and preserves current settings, including owner/delegate access. Review and publish to make it live. Current license and schema limits apply; a restore cannot recreate removed paid capacity on Free. Role definitions, media and WordPress content are outside these revisions.

Owners can use Settings & tools → Activity & recovery for one-hour safe mode and stale write-lock recovery. Recent locks cannot be cleared until one minute has passed. For server-level recovery, temporarily add define( 'WPA_RECOVERY_MODE', true ); to wp-config.php; this bypasses PanelKind restrictions site-wide while native WordPress permissions remain. Remove it after repair. wp panelkind recover clears a stale configuration lock; wp adminer recover remains an alias.

Deactivation retains configuration and stops presentation/policy hooks and role-base synchronisation. Uninstall removes plugin management grants. Configuration is kept unless Delete plugin configuration when uninstalling was explicitly enabled. Cleanup never deletes users or ordinary site content; assigned/default custom roles are retained with their last permissions.

Back to documentation