ImagePipe's automatic theme replacement works by matching image placements to presets: wherever a theme location is covered by an existing preset, product_card in the shop loop, product_page on the single product template, category_banner on archive pages, the corresponding images are served through ImagePipe without any extra markup. For a theme built on standard WooCommerce template hooks, this covers most of the visible catalog out of the box.
A custom theme, by definition, introduces placements the automatic matching doesn't already know about: a related-products carousel with its own dimensions, a lookbook grid, a hero banner built from a custom field rather than the featured image. For these, automatic detection has nothing to match against, there's no universal heuristic that can guess what size and resize mode an arbitrary custom template block should use. The fix isn't a workaround, it's the intended path: create a preset for that placement, dimensions, resize mode, quality, allowed formats, and reference it explicitly from the theme code at the point where the image is rendered.
Images inserted through the Gutenberg block get this wiring automatically, but a theme developer working outside the block, in a custom template file or a PHP loop, calls the same underlying logic directly against the adapter's functions rather than going through the editor. The result is identical for the visitor: a WebP or AVIF variant sized and compressed according to the preset, served from cache after the first request.
None of this involves a network call to an external service. There's no hosted transformation API to reach for imagepipe.devrunai.re or anywhere else, the engine runs inside the WordPress/WooCommerce install itself, as a PHP plugin. A custom placement that isn't wired to a preset simply falls back to serving the original file unprocessed, it never fails open to a broken external request or a blocked outbound connection.