WordPress & WooCommerce

Page builders

Glozr detects WordPress page builders during content sync and renders pages through each builder's native API. This means the chunks fed to the retriever match what visitors actually read — not the raw shortcodes or empty post bodies that vanilla reads would return.

Why detection matters

Most page builders stash their layout in custom post meta rather than post_content, which breaks naive content reads:

• Elementor — layout stored in _elementor_data postmeta. A vanilla content read returns empty.
• Bricks — layout in _bricks_page_content_2. Requires the builder to render.
• Oxygen — only shortcode stubs appear without builder processing.
• Beaver Builder — falls back to a stripped-down HTML without proper rendering.
• Divi — shortcode-encoded layout that requires primed post globals to render correctly.

Supported builders

Every renderer is wrapped in error handling. If a builder throws, the plugin falls through to vanilla WordPress processing instead of failing the sync.

Divi's special requirements

Divi stores layouts as shortcodes in post_content, but third-party plugins (Yoast, Jetpack, etc.) only run their filters when there's a proper post context in scope. The plugin primes $GLOBALS['post'] and calls setup_postdata() so those filters fire correctly, then restores the previous context — even if a downstream call errored.

Customization hook

Use the pitchbar_post_content_html filter to post-process the rendered HTML regardless of which builder produced it. Returning an empty string from this filter suppresses the row from being synced at all, which is useful for excluding specific post types or templates from the knowledge base.

Limitations

Server-side rendering cannot capture:

• Dynamic content (live cart counts, user-specific blocks).
• Conditional display rules that depend on the visitor.
• JavaScript-rendered content that's only assembled in the browser.