SleekView for WP Staging Pro: staging clones & pushes as tables
WP Staging Pro stores every staging clone, its excluded tables, and push history inside wp_options under wpstg_existing_clones and related keys. SleekView reads those directly so staging operations become an auditable workspace rather than per-clone drilling.
♾️ Lifetime License available
Staging environments as a tracked inventory
WP Staging Pro persists each staging clone, its excluded tables, and the most recent push timestamp inside wp_options under wpstg_existing_clones. The default plugin UI lists clones as cards with action buttons. That works for one clone but becomes unwieldy on installs that maintain a stable staging environment, a per-release review staging, and ad-hoc developer clones at the same time.
SleekView reads the existing-clones option directly and unpacks each clone into a row. Clone name, source database prefix, destination prefix, included tables, excluded tables, and last-push timestamp become sortable columns. A second view surfaces push history with timestamp, scope, and outcome for each push from staging back to production.
Inline actions (delete a stale clone, refresh from production, push selected changes) call WP Staging Pro's own programmatic endpoints where available, so the same hooks fire as in the plugin UI. Read-only views are the default for non-admin roles.
Workflow
Audit every staging clone and push in one workspace
Point at wpstg_existing_clones
Join push history
wpstg_push_history alongside clones so each clone row shows its most recent push outcome and timestamp. Audits sit in one workspace rather than two tabs.
Surface staleness
Save cleanup presets
Sample columns
A typical staging clones view
wp_options (key: wpstg_existing_clones, wpstg_push_history)
| Clone | Prefix | Excluded tables | Created | Last push | Status |
|---|---|---|---|---|---|
| staging | wp_stgng_ | wp_options, wp_users | Apr 02 | Apr 24 | Active |
| review-r142 | wp_r142_ | wp_users | Apr 18 | Apr 22 | Active |
| dev-alex | wp_alex_ | wp_users, wp_woocommerce_* | Mar 12 | Mar 14 | Stale |
| old-r118 | wp_r118_ | wp_users | Jan 04 | Jan 04 | Archived |
Comparison
Default WP Staging Pro admin vs SleekView
Default WP Staging Pro admin
- Clones list as cards, not a sortable inventory
- Excluded-table audits need opening each clone individually
- Stale clones accumulate silently in option storage
- Push history isn't a flat queryable view
- Per-developer clone usage isn't a saved view
SleekView
-
Unpack
wpstg_existing_clonesinto a flat view - Surface included and excluded tables as columns
- Filter by prefix to identify per-developer clones
- Sort by age to find stale clones for cleanup
- Audit push history with scope and outcome columns
Features
What SleekView gives you for WP Staging Pro
Clone inventory
Every staging clone in one ranked list with prefix, excluded tables, and last-push timestamp. Useful when reviewing what staging environments exist before a release cutover.
Excluded-table audit
Surface excluded-tables list as a column. Confirm every clone excludes wp_users consistently, which is the typical safe-staging default.
Stale-clone cleanup
Filter clones whose last-push timestamp is older than thirty days. Those are usually stale developer clones safe to archive after stakeholder review.
Audience
Who uses SleekView for WP Staging Pro
Release engineers
Pre-cutover staging review confirming the right clone exists for the release, with excluded-tables and last-push visible. Reduces accidental pushes from the wrong clone.
Developer leads
Per-developer clone usage view, with prefix patterns making per-developer clones identifiable. Useful for cleanup conversations and for clone-naming convention reviews.
Operations
Audit excluded-tables consistency across every clone. Confirms safe-staging defaults are honored and catches drift before a push accidentally overwrites production user data.
The bigger picture
Why staging clones need audit discipline
Staging environments are easy to create and surprisingly hard to retire. WP Staging Pro's friendly clone wizard means every developer can spin up a per-release staging copy in two clicks, which is exactly the feature that turns into a hygiene problem six months later. The default plugin UI lists clones as cards with action buttons, designed for a maintainer with two or three clones at a time.
Reading wpstg_existing_clones directly turns that card grid into a sortable inventory. Stale clones older than thirty days surface in a single filter. Excluded-tables drift between developer clones becomes a column scan.
Push history from staging back to production becomes a queryable audit trail rather than a hidden log. Once that audit habit exists, staging environments shift from a personal-productivity tool to a tracked engineering practice, with clear retirement criteria and visible per-developer activity. That visibility is the difference between a staging discipline that scales past a small team and one that collapses under its own clone accumulation.
Questions
Common questions about SleekView for WP Staging Pro
Yes. Push events are logged with timestamp, scope, and outcome. SleekView surfaces them as a separate sortable view alongside the clone inventory, so audits answer both "which clones exist" and "what pushes happened from them".
 Yes for capability-gated admins. WP Staging Pro exposes a programmatic push endpoint that SleekView calls on row actions, so the same hooks and validation steps fire as in the plugin UI.
 Partially. The free WP Staging plugin supports clone creation but not push-back, so the push-history view appears empty. The clone inventory view works the same on both versions.
 Yes if WP Staging Pro captured that field, which recent Pro versions do. Older clones that pre-date the user-tracking feature appear with a blank created-by column.
 Yes. The existing-clones option is typically small per install (a handful of clones at most), and aggregation across multi-tenant management dashboards happens in SleekView's indexed cache.
 Yes. Reads are non-destructive and capability-gated. Inline actions call plugin endpoints rather than rewriting option blobs directly, so serialized integrity is preserved.
 Yes for capability-gated admins. The plugin's delete-clone endpoint is called from row actions, which removes both the option metadata and the cloned database tables consistently.
 Yes. Multisite-aware clones are surfaced with their subsite scope as a column, and per-subsite excluded-tables become joinable subview rows. Multisite staging audits become viable in a single workspace.
 Pricing
More than 1000+
happy customers
Explore our flexible licensing options tailored to your needs. Upgrade your license anytime to access more features, or opt for a lifetime license for ongoing value, including lifetime updates and lifetime support. Our hassle-free upgrade process ensures that our platform can grow with you, starting from whichever plan you choose.
Lifetime ♾️
Most popular
EUR
once
- Unlimited websites
- Lifetime updates
- Lifetime support
...or get the Bundle Deal
and save €250 🎁
The Bundle (unlimited sites)
Pay once, own it forever
Elevate your WordPress site with our exclusive plugin bundle that includes all of our premium plugins in one package. Enjoy lifetime updates and lifetime support. Save significantly compared to buying plugins individually.
What’s included
-
SleekAI
-
SleekByte
-
SleekMotion
-
SleekPixel
-
SleekRank
-
SleekView
€749
Continue to checkoutBrowse more
- Woocommerce Ebay Integration
- Yith Woocommerce Quick View
- Woocommerce Zip Checkout
- Woocommerce Waitlist
- Woocommerce Shipworks
- Wc Vendors
- Edd Frontend Submissions
- Dokan
- Woocommerce Instamojo
- Woocommerce Realex
- Restropress
- Woocommerce Octobat
- Surecart
- Woocommerce Frontend Manager
- Woocommerce Affiliatewp Integration