✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount
✨ New Plugin Alert ✨ SleekRank is now available with €50 launch discount

SleekView for Stackable Blocks: pages, posts, and block usage as tables

Stackable stores block markup in post_content with the ugb/* namespace for v2 blocks and stackable/* for v3. SleekView indexes both and surfaces version drift as a filterable column.

♾️ Lifetime License available

SleekView table view for Stackable Blocks

Stackable v2 and v3 usage in one view

Stackable is a Gutenberg-native block library that went through a major version change from v2 (ugb/* namespace) to v3 (stackable/* namespace) with overlapping support during the transition. Block instances are stored as block markup inside post_content, so pages can carry a mix of v2 and v3 blocks across years of content. Reusable blocks live in the standard wp_block CPT.

SleekView reads post_content across pages, posts, and any public CPTs, indexes Stackable block usage by namespace and block name, and surfaces version drift as a filterable column. Filter to posts still using ugb/* v2 blocks to plan v3 migration. Filter to posts using a specific v3 block to audit coverage. Sort by last edited to find recently touched pages that still carry legacy markup.

Inline edits to status, slug, and author write through standard WordPress update calls. The block markup in post_content stays editable in the block editor where the Stackable controls live.

Workflow

From v2/v3 confusion to a Stackable migration audit

1

Index Stackable block usage

SleekView parses post_content for ugb/* and stackable/* block comments and indexes usage per post. Every Stackable-touched page becomes a queryable record.
2

Add version columns

Block usage list, version (v2 or v3), last edited, author, status, and post type become first-class columns. Filter chips replace ad-hoc database queries.
3

Save migration views

Pin a v2-only view, a v3-coverage view, and a deprecated-blocks view. Each audit becomes a one-click slice instead of a custom database query.
4

Inline-edit metadata

Update status, slug, or author from the row during a migration pass. Block markup stays untouched; the block editor remains the source of truth for block content.

Sample columns

A typical Stackable block usage view

Posts grouped by Stackable v2 (ugb/*) and v3 (stackable/*) block usage.
Source: wp_posts (post_content with ugb/* and stackable/* block markup) + wp_postmeta + wp_block
Title Type Stackable blocks used Version Status Last edited
Spring landing Page stackable/hero, stackable/card v3 Published Apr 24, 2026
Old features page Page ugb/feature-grid, ugb/cta v2 (legacy) Draft Apr 11, 2026
Pricing v3 Page stackable/pricing-box v3 Published Apr 22, 2026
Decommissioned Page ugb/header v2 (legacy) Trashed Feb 8, 2026

Comparison

Default Stackable admin vs SleekView

Default Stackable admin

  • No way to filter posts by which Stackable block they use
  • v2 versus v3 drift is invisible from any list view
  • Deprecated ugb/* blocks require SQL to find
  • Reusable block reference counts are not surfaced
  • Bulk status edits across pages using a specific block are manual

SleekView

  • Filter posts by Stackable block and version
  • Saved views for v2 migration, deprecated blocks, or v3 coverage
  • Inline edit status and slug without opening the block editor
  • Reusable block reference counts as a filterable column
  • CSV export for v2-to-v3 migration planning deliverables

Features

What SleekView gives you for Stackable Blocks

Version drift as a filter

Find every page still using v2 ugb/* blocks by parsing block comments in post_content. v2 to v3 migration audits become a filter pass instead of an estimation.

Deprecated block detection

Spot pages using deprecated Stackable blocks before they break on the next upgrade. The grid surfaces them with last-edited and author so cleanup gets owned.

Metadata edits

Update status, slug, and author from the row during a migration pass. Block markup in post_content stays untouched; the block editor remains the only place to change blocks.

Audience

Who uses SleekView for Stackable Blocks

Agencies

Audit Stackable v2 to v3 migration progress across client sites. Per-client saved views surface which pages still need migration without an ongoing investigation.

Development teams

Find every page using a specific Stackable block before refactoring or removing it. Block-usage filters replace SQL on post_content for ordinary audits.

Site owners

Plan the v2 to v3 migration with full visibility of which pages carry legacy markup. Migration becomes a tracked project instead of a never-finished investigation.

The bigger picture

Why Stackable v2 to v3 migrations need an audit surface

Stackable's transition from v2 to v3 was a significant rewrite that introduced a new block namespace and a new editor experience while keeping the v2 blocks functional for backward compatibility. That decision protected long-running sites from breaking on upgrade, but it also created a new operational question: which pages still use v2 blocks, and which have been migrated to v3. The default WordPress admin doesn't surface block usage at all, so version-drift audits across years of content require database grep or page-by-page inspection.

Agencies running Stackable across multiple client sites face the same question per client. In-house teams running Stackable on a single site face it across years of campaign pages. A queryable block usage index changes that audit fundamentally.

Filter to v2 pages to plan migration. Surface deprecated block usage before the next upgrade. Track v3 coverage across the site.

Migration becomes a measurable project with a backlog instead of an ongoing investigation. Agencies use the grid output as a client deliverable; in-house teams use it as the migration plan they finally have.

Questions

Common questions about SleekView for Stackable Blocks

Block instances are stored as Gutenberg block markup inside post_content. v2 blocks use the ugb/* namespace, v3 blocks use stackable/*. Reusable blocks live in the wp_block CPT. SleekView reads both namespaces directly to build the audit grid.

 

Stackable went through a major version change from v2 to v3 with a new block namespace to allow side-by-side support. Older posts keep their ugb/* blocks, newer posts use stackable/*. The grid surfaces both versions so migration planning has an audit surface.

 

No. Block content stays inside the WordPress block editor where Stackable's controls and design panel work as designed. SleekView edits surrounding metadata (status, slug, author) and indexes block usage as a filterable column. The block markup itself never gets touched.

 

Yes. The grid surfaces which pages still use v2 ugb/* blocks and which have moved to v3. Filter to v2-only pages, prioritize by last-edited or status, and the filtered list becomes the migration backlog. Agencies use this as a recurring deliverable for older Stackable client sites.

 

Yes. The grid surfaces deprecated block usage as a saved view, with last-edited and author columns showing who built each page. That audit takes one filter pass instead of a database-wide grep across post_content.

 

Yes. Reusable blocks in the wp_block CPT surface alongside posts with reference counts showing how many pages use each one. Reusables with reference count zero are easy to prune during a migration or quarterly housekeeping pass.

 

Yes. SleekView is read-mostly and inline edits use standard WordPress update calls. Block markup in post_content is never touched, which means the block editor and the front-end render behave exactly as before. Any plugin hooks on metadata changes still fire normally.

 

Yes. Every saved view exports to CSV with the visible columns including block usage list, version, status, and last edited. Migration deliverables use the exports directly as the planning document.

 

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.

Starter

€79

EUR

per year

  • 3 websites
  • 1 year of updates
  • 1 year of support

Pro

€149

EUR

per year

  • Unlimited websites
  • 1 year of updates
  • 1 year of support

Lifetime ♾️

Most popular

€249

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