SleekView for Avada: Fusion Builder content & options as tables
Read directly from postmeta keys Fusion Builder writes (pyre_*, fusion_options, fusion_builder_status) and any custom post type. Sort, filter, and inline-edit Avada pages without opening each one — and surface page-option meta as real columns.
♾️ Lifetime License available
Stop opening Avada pages one at a time to check options
Avada's strength — every page can override hundreds of theme options through Fusion Page Options — is also the reason its admin Pages list tells you almost nothing. Header style, sidebar layout, page background, footer visibility, custom CSS — all of that lives in postmeta keys like pyre_header_position, pyre_sidebar_pos, pyre_page_bg_color. The default WordPress Pages screen shows title, author, date. SleekView reads the pyre_* meta keys directly so you build the columns you actually need, then sort by template or filter by header style without leaving the list.
Fusion Builder stores its content in the standard post_content field as shortcodes, but its status flags (live editor used, last-edited timestamp, builder version) and section presets sit in their own meta keys. SleekView joins them so a content audit view can show every page using a deprecated fusion_builder_container attribute or every page still on a Fusion Builder version older than your current install. On large multi-site rollouts it falls back gracefully when keys are missing, so the same view works across staging, prod, and freshly imported demos.
Inline edits go through the standard update_post_meta path so Avada's option cache invalidates and the next front-end render picks up the change. Bulk-flip thirty pages from "100% width" to "boxed" by editing the pyre_page_layout column directly — no clicking through Fusion Page Options thirty times. The same applies to header visibility, sidebar overrides, and any custom meta you've layered on top of Avada with ACF or Meta Box.
Workflow
How SleekView reads your Avada install
Pick the source post type
page, post, fusion_template, or any custom post type Avada or a child theme registers. SleekView detects which pyre_* meta keys are in use on that type.
Compose your column set
pyre_* or fusion_* meta key. The agent UI lists keys actually present in your installation so you don't have to guess.
Save and scope the view
Edit inline and ship
update_post_meta so Avada's option cache invalidates and front-end renders pick up the change.
Sample columns
A typical Avada pages view
posts and postmeta tables, joining the pyre_* meta keys Fusion writes per page so theme options become real columns.
wp_posts (page, post, custom types) + wp_postmeta (pyre_*, fusion_*)
| Title | Template | Header style | Sidebar | Last edited | Status |
|---|---|---|---|---|---|
| Homepage | 100% width | Top — v6 | None | Apr 24 | Published |
| About | Boxed | Side — left | Default | Apr 22 | Published |
| Services | 100% width | Top — v4 | None | Apr 21 | Published |
| Contact | Boxed | Top — v6 | Default | Apr 18 | Published |
| Spring landing | 100% width | Top — v6 | None | Apr 17 | Draft |
Comparison
Default WordPress Pages list vs SleekView on Avada
Default WordPress Pages list
- Fixed columns — title, author, date — no view of Fusion Page Options
- Header, sidebar, and layout overrides require opening Fusion Page Options per page
- No way to filter pages by Avada template, header style, or sidebar setting
-
pyre_*meta keys are invisible in the list — you can't audit overrides - Bulk-editing layout options means clicking through every page individually
SleekView
-
Read directly from
pyre_page_layout,pyre_header_position,pyre_sidebar_posand otherpyre_*keys - Inline-edit Fusion Page Options across many rows in one pass
- Custom columns from any postmeta key Avada or your child theme writes
- Save filtered views per role (e.g. "Pages still on Header v4")
- Switch between table and kanban views grouped by template or header style
Features
What SleekView gives you for Avada theme
Audit Fusion Page Options at a glance
Build a view that lists every page with its layout, header style, sidebar position, and footer visibility as columns. Spot mismatches before a redesign without opening Fusion Page Options on each page.
Inline-edit pyre_* meta in bulk
Flip boxed to 100% width right in the row. Bulk-update layout, header, or sidebar across dozens of pages in seconds, with Avada's option cache invalidating through the standard meta-update hooks.
Filter by template, builder status, or version
Combine Fusion Builder version, last-edited date, header style, and any custom meta. Save the filter as a named view your design team reuses every release — no rebuilding it after each Avada update.
Audience
Who uses SleekView for Avada
Theme rollouts and audits
Before swapping header styles site-wide, list every page using each header version, sidebar layout, and template. Bulk-update the laggards in one pass instead of clicking through Fusion Page Options dozens of times.
Performance reviews
Filter pages by Fusion Builder version, custom-CSS length, or background-image presence to surface the heaviest pages. Pair with a column for last-edited date so you focus refactors on pages that still get traffic.
Multi-author content teams
Editors see only their assigned pages with template and header columns relevant to their section. Inline-edit layout settings without learning the Fusion Page Options screen — drop-downs in the row are enough.
The bigger picture
Why row-level Avada audits beat per-page Fusion Page Options clicks
Avada's Fusion Page Options panel is comprehensive, which is also why it's hard to govern across a site of any real size. Each page carries dozens of overrides — header style, sidebar position, page layout, custom CSS, footer visibility — and the only way to see them in the default WordPress admin is to open each page and scroll through the panel. That works for a five-page brochure site.
It does not work for an agency rolling Avada out across a multisite of regional offices, a business swapping header styles between brand refreshes, or a content team trying to standardise sidebar layout after years of ad-hoc choices. The default Pages list shows title, author, date. The pyre_* meta keys that drive Avada's per-page behaviour are invisible.
SleekView turns the same data into the workspace each team needs: designers see every page using a legacy header version, editors see template and sidebar columns next to titles, ops bulk-update layout settings before a redesign. Same database, same hooks, dramatically less clicking through Fusion Page Options.
Questions
Common questions about SleekView for Avada theme
Yes. Fusion Page Options write to standard postmeta keys prefixed pyre_ (and a few fusion_ keys for builder state). SleekView lists them in the agent UI, surfaces only those actually used in your installation, and exposes them as columns. No hooks into Avada's internal classes are required — it's plain WordPress meta the whole way.
Yes. SleekView writes through update_post_meta, which fires the same hooks Avada listens to for its per-page option cache. The next front-end render picks up the change. Bulk operations iterate through the same path so cache invalidation matches what would happen if a human had clicked Save in Fusion Page Options.
Yes. SleekView treats all meta keys the same way regardless of which plugin wrote them. Add ACF fields, Meta Box fields, or hand-rolled pyre_* overrides in the same view. The agent UI shows fields actually present so you don't have to remember key names from a child-theme file.
Avada page templates are still standard WordPress page templates referenced by the _wp_page_template meta key, so SleekView shows them as a column out of the box. For Fusion Templates (the post type for header/footer/global page templates), point a separate view at the fusion_template post type and surface its settings the same way.
Theme Options live in the options table as serialized arrays under the fusion_options key, not in postmeta. SleekView focuses on row-level data so it's not the right tool for a single options blob — but per-page overrides (the pyre_* keys) are exactly what it surfaces.
No — it's an additional admin surface. Fusion Page Options stays where it is for designers who like the long-form panel. SleekView gives ops, content, and audit teams the row-level views they actually need without disturbing the Avada admin or rewriting workflows that already work.
 
Queries hit the standard WordPress indexes on posts and postmeta. Filters and sorts use indexed columns where possible; meta-key joins are limited to keys you've explicitly added to the view so you don't pay for joins you're not displaying. Pagination uses keyset where the column set allows it.
Yes. Avada applies the same pyre_* meta scheme to posts, products, portfolios, and custom post types registered by Fusion Core. Point SleekView at any of those post types and the same options surface as columns. One view per post type or a tabbed page that switches between them.
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 checkout