WP Clone Pro persists each clone definition, run timestamp, and target destination inside wp_options under wpc_clones and a small family of related keys. The default plugin UI runs clones as confirmation modals: pick the source, pick the destination, click clone, wait. That works for occasional cutover work but leaves no inventory of what was cloned where, by whom, and when.

SleekView reads the saved clone definitions directly. Source URL, destination URL, last-run timestamp, run direction, and the user who initiated it become sortable columns. A second view exposes destination targets (staging, review, disaster recovery) with their own URLs and configuration so portfolio-wide audits become possible without per-install drilling.

Inline edits route through the plugin's option setters where they exist, falling back to direct writes with rollback snapshots for keys that have no programmatic API. Read-only views are the default for non-admin roles, so the audit surface stays safe on production.

Cloning is the kind of operation that gets defended with a confirmation modal and then forgotten. The plugin asks once, the user clicks, the destination gets overwritten, and no audit trail exists outside the plugin's internal option blob. That works fine until a junior staffer accidentally clones production over a client's staging environment that was being used for in-flight QA.

The conversation that follows hinges on knowing exactly which clone ran, by whom, against which destination, and when. Reading wpc_clones directly turns that question into a sortable column. Per-user run counts surface as a column for capacity planning.

Destination drift between team members becomes a filter. Compliance trails for regulated industries become CSV exports rather than logging projects. Once the audit habit exists, cloning shifts from a high-trust operation to a tracked one without slowing the workflow down, which is the only way cloning practices scale safely past three or four engineers.