WP Clone is a single-purpose backup plugin: package the entire site as a single ZIP, store it under /wp-content/uploads, and restore from URL or upload on the target install. The default UI is intentionally minimal: a button to create, a field for the URL to restore from, a list of existing ZIPs. That minimalism is the plugin's selling point and the reason it is still widely used. It is also why the question 'how many clones did we generate last quarter?' has no straight answer in the default admin.

SleekView reads the same wp_options entries WP Clone writes for each clone and restore and reconciles them with the ZIPs on disk. Each row carries the started_at timestamp, the job type (Clone or Restore), the archive name, the size, the duration, and the outcome. A 1.4 GB scheduled clone sitting next to a Restore that pulled from a staging URL gives a project manager a real record of cutover activity instead of a flat folder listing.

Filters carry the conversation. Filter to type equals Restore for the project window and the grid becomes a defensible audit of how often the destination actually received an archive. Same plugin, same ZIPs, one sortable view that finally answers the questions a multi-week migration project generates.

WP Clone's reason for existing is simplicity: one button, one ZIP, one URL on the other end. That deliberate scope keeps the plugin easy to recommend. It also leaves the data the plugin produces on the floor.

Sites that use WP Clone for staging-to-prod cycles or for periodic safety snapshots accumulate hundreds of archives over a year, and the default screen surfaces none of it as an aggregate. SleekView fixes the surface without changing the plugin. A KPI filter answers 'is the cloning workflow still in use?' A type filter answers 'how often are we restoring?' A size column warns when archives are getting big enough that a restore over a hotel WiFi is going to be a problem.

Same plugin, same ZIPs, much better posture for the team relying on them.