Page builders
WP Media Cloud works with all major WordPress page builders. In most cases no configuration is needed — images in page builder layouts are served from cloud storage automatically once WP Media Cloud is configured. This document covers how each supported page builder interacts with WP Media Cloud and any known limitations specific to that builder.
How page builders work with WP Media Cloud#
There are two ways a page builder can output image URLs, and WP Media Cloud handles both:
Attachment ID-based rendering — the page builder stores an attachment ID and calls WordPress’s attachment URL functions at render time. WP Media Cloud filters those functions at priority 99 and returns CDN URLs automatically. No extra work needed. Bricks Builder, Elementor, Etch, WPBakery, and most Breakdance and Oxygen elements work this way.
Stored URL string rendering — the page builder stores the full image URL as a string in postmeta when the image is inserted, then outputs that string at render time without going through WordPress attachment functions. WP Media Cloud handles these via its content URL rewriter, which scans the final HTML output and replaces any local upload URL with the CDN base URL. Divi and Beaver Builder use stored URL strings for most module images.
Bricks Builder#
Bricks renders all images through standard WordPress attachment functions. WP Media Cloud’s CDN URLs are applied at priority 99, after Bricks has completed its own image size adjustments at priority 10. Dynamic data fields from ACF, Meta Box, JetEngine, Pods, and other field plugins also benefit from WP Media Cloud’s URL filtering automatically.
No known limitations. No configuration required.
Elementor#
Elementor renders all image and media through standard WordPress attachment functions — both classic widgets (Image, Image Box, Image Gallery) and Atomic Widgets (Image Transformer, srcset). WP Media Cloud’s CDN URLs are applied at priority 99.
No known limitations. No configuration required.
Etch#
Etch uses wp_get_attachment_image_src(), wp_get_attachment_image_srcset(), and wp_get_attachment_metadata() exclusively for image rendering. All are filtered by WP Media Cloud at priority 99.
No known limitations. No configuration required.
Beaver Builder#
Beaver Builder stores image URLs as strings in module settings (the photo_src prop) and outputs them directly without calling WordPress attachment functions. WP Media Cloud handles this via its content URL rewriter, which runs at priority 99 on the_content and replaces local upload URLs with CDN URLs in the rendered HTML. Several Beaver Builder admin and data functions do call WordPress attachment functions directly and also return CDN URLs correctly.
Known limitation — custom cropped images: Beaver Builder’s Photo module supports on-demand custom cropping. Cropped image variants are stored in Beaver Builder’s local cache directory (/wp-content/uploads/bb-plugin/cache/) as local files not tracked by WP Media Cloud. Cropped images are served from the local server rather than the CDN. This only applies when a custom crop is explicitly set on a Photo module. Uncropped images use CDN URLs normally.
Divi#
Divi stores image URLs as strings in module props inside postmeta when images are inserted in the Divi editor. On render, Divi’s Image module outputs the stored URL string directly inside an <img> tag without calling WordPress attachment functions. WP Media Cloud handles this via its content URL rewriter, which runs at priority 99 on the_content after Divi has rendered its shortcodes, and replaces local upload URLs with CDN URLs. Several Divi modules — Background, Gallery, PostSlider, and PostTitle — do call WordPress attachment functions and return CDN URLs directly.
Known limitation — responsive image cache: Divi maintains an internal cache keyed by the URL returned from wp_get_attachment_url(). When WP Media Cloud is active, this key is the CDN URL. Divi’s module props store local URLs, so reverse lookups from a local URL to an attachment ID against the CDN-keyed cache may fail. This affects Divi’s internal responsive image generation for prop-stored images. Basic image display is not affected because the content URL rewriter covers the final HTML output.
Breakdance#
Breakdance renders standard images and dynamic data fields through WordPress attachment functions. WP Media Cloud filters these at priority 99 and returns CDN URLs. Dynamic data fields including post featured images, ACF image fields, WooCommerce product images, and Toolset fields all benefit automatically.
Known limitation — on-demand image resizer: Breakdance has an on-demand image resize endpoint (Singularity) that creates custom-dimension thumbnails server-side. It builds the returned URL from wp_upload_dir()['url'] rather than wp_get_attachment_url(), so resized image URLs point to the local origin rather than the CDN. This only affects Breakdance’s custom-resize feature. All standard element image display uses WordPress attachment functions and returns CDN URLs correctly.
Oxygen Builder#
Oxygen Builder shares an identical codebase with Breakdance — it sets BREAKDANCE_MODE = 'oxygen' to distinguish itself at runtime. All compatibility notes from the Breakdance section above apply to Oxygen without change. WP Media Cloud detects Oxygen and Breakdance separately and reports them independently on the Integrations tab.
Known limitation — on-demand image resizer: Same as Breakdance. The Singularity image resize endpoint builds URLs from wp_upload_dir()['url'] and returns local origin URLs for on-demand-resized images.
WPBakery#
WPBakery stores attachment IDs and resolves image URLs at render time through WordPress attachment functions. WP Media Cloud filters these at priority 99. The rewrite_content_urls() content filter provides a secondary catch for any URL strings that reach the final HTML, though in practice the ID-based path means most URLs are already rewritten at the filter level.
Known limitation — image filter feature: WPBakery has an admin-only image filter tool that applies colour filters to images using PHP GD. It reads the local file from disk using get_attached_file(). If local file removal is enabled in WP Media Cloud and local copies have been deleted, the WPBakery image filter preview and apply operations will fail for offloaded images. This is an admin-only feature — frontend image display is not affected.