SleekView for Magento Bridge: synced catalog & orders as tables
SleekView reads the bridge's per-product postmeta (_magento_product_id, _magento_store_view, _magento_synced_at) and the store-view cache in wp_options. Sort by store view, filter by sync state, and fix mismatches inline.
♾️ Lifetime License available
Magento multi-store state, visible in WordPress
Magento (Adobe Commerce) supports multi-store, multi-store-view setups by design, and bridges to WordPress mirror part of that catalog into WP for content and SEO use. The bridge writes per-product meta to track the Magento side: _magento_product_id, _magento_sku, _magento_store_view, _magento_synced_at, plus a store-view name cache in wp_options (magento_store_views).
The default WP Products screen sees none of this. SleekView reads wp_posts (whichever post type the bridge uses, often product or a custom magento_product type) joined with the Magento meta keys plus the store-view cache. The result is a single table showing the WP post, Magento product ID, store view label, sync state, and last-sync timestamp.
Bulk actions can fire the bridge's own magento_resync_product hook on a filtered subset, so retries use the bridge's existing rate limiting and error handling. Inline edits flow through update_post_meta() the same way the bridge's own UI does.
Workflow
How SleekView reads your Magento Bridge state
Pick the source
Compose columns
magento_store_views, sync state, and last-sync timestamp.
Save and scope per role
Edit inline or bulk-update
magento_resync_product on a filtered subset. The bridge picks up changes on the next cron.
Sample columns
A typical Magento Bridge view
_magento_product_id and _magento_store_view against bridge-managed product rows so every entry shows its real Magento mapping.
wp_posts (post_type=product or magento_product) + wp_postmeta + wp_options
| WP post | Magento SKU | Magento ID | Store view | Sync status | Last sync |
|---|---|---|---|---|---|
| Black tee shirt | TEE-BLK | 44218 | us_en | In sync | Apr 24 |
| Ceramic mug | MUG-CER | 44219 | eu_de | Drifted | Apr 23 |
| Art poster A2 | POSTER-A2 | us_en | Unmapped | ||
| Natural tote bag | TOTE-NAT | 44221 | uk_en | In sync | Apr 24 |
Comparison
Default Magento Bridge admin vs SleekView
Default Magento Bridge admin
-
Store-view assignment in
_magento_store_viewisn't visible in the Products list - Drifted products (changed in Magento, not yet pulled) only show in the bridge log
- Multi-store-view catalogues need manual checks per store view
-
Unmapped products (empty
_magento_product_id) require opening each one -
Magento attribute meta in
_magento_attributesisn't surfaced in the list
SleekView
-
Reads
_magento_product_id,_magento_sku,_magento_store_viewas columns -
Resolve store-view codes to names via
magento_store_viewscache - Filter drifted products in one saved view per store view
-
Bulk-trigger
magento_resync_producton selected rows -
Surface specific Magento attributes from
_magento_attributesas their own columns
Features
What SleekView gives you for Magento Bridge for WordPress
Store-view state per row
Store-view label, Magento ID, and last-sync timestamp on every product row. Multi-store catalogues become legible without bouncing between admin pages.
Filter drift across store views
Save "Drifted on eu_de this week" as a recurring view. The German merchandiser sees only what needs attention on their store view.
Bulk re-pull from Magento
Trigger magento_resync_product on a filtered subset. The bridge handles the API call on its next cron, using its own retry logic.
Audience
Who uses SleekView for Magento Bridge
Multi-store merchandisers
Filter by store view to focus on US or EU or APAC catalogues. Drift filters surface products that changed in Magento but haven't pulled across to WP.
Integration engineers
Spot unmapped rows quickly and bulk-resync. The Magento API rate limits are handled by the bridge; SleekView just gives the right list of items to retry.
Support
When a customer reports a price or stock mismatch, see the WP-side and Magento-side state in the same row. Resolves most "why is this different" tickets at the first touch.
The bigger picture
Why Magento multi-store needs WP-side visibility
Magento's strength is multi-store, multi-store-view catalogues with deep attribute systems. The cost is operational complexity: a single product can have different prices, names, and statuses across store views. When that catalog is mirrored into WordPress for content reasons, the WP-side admin shows one row per product and hides the multi-store nuance entirely.
The bridge writes per-store-view meta, but the default Products screen ignores it. SleekView reads what the bridge already stored, resolves store-view codes against the bridge's own cache, and presents a per-store-view filterable list. Regional merchandisers see only their store view; integration engineers see drift across all views; support sees the same row state the customer experiences.
The bridge keeps syncing, the Magento side stays canonical, and the WordPress side finally has admin tooling that matches the data complexity.
Questions
Common questions about SleekView for Magento Bridge for WordPress
Both. The agent UI scans for keys actually present on your install, so it adapts to _magento_product_id, _magento_entity_id, or whatever specific keys your bridge writes.
Yes. If the bridge stores Magento attributes as serialised meta in _magento_attributes or as separate keys per attribute, SleekView lets you pick them in the column picker and shows them inline.
Store-view codes (us_en, eu_de) are resolved against the bridge's cache in wp_options (typically magento_store_views). The column shows the configured label instead of the raw code.
Inline edits update postmeta via update_post_meta() and fire the standard updated_post_meta action. Bridges that listen on that hook propagate changes; others reconcile on the next sync.
Yes. Bulk actions call the bridge's own resync hook per row, the same path the bridge uses for its built-in resync buttons. The bridge handles API rate limits and retries.
Magento configurable products map to grouped or variable WP products depending on the bridge. SleekView shows the parent row with child counts; variant-level detail goes into a per-product detail panel.
If the bridge mirrors orders to shop_order with Magento meta (_magento_order_id, _magento_order_status), build a second tabbed view for orders alongside the products view.
Each store view multiplies the postmeta rows, so for very large catalogues, narrow the SleekView with a store-view filter before adding heavy joins. Indexed lookups handle the per-store-view queries efficiently.
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
- Printify Integration
- Wcam Marketplace
- Woocommerce Zoho Books
- Wpc Frequently Bought Together
- Edd Paypal Pro
- Woocommerce Fast Checkout
- Woocommerce Blockonomics
- Woocommerce Bulk Discounts
- Woocommerce Quick Order
- Woocommerce Product Addons Pro
- Woocommerce Frontend Manager
- Woocommerce Cashfree
- Woocommerce Stripe Gateway
- Woocommerce Checkout Addons
- Edd Frontend Submissions