Skip to main content
On a WooCommerce store, WPOS customizes the store’s templates (product pages, cart, checkout, and archives) from chat. It checks how the store is actually built first, picks the approach that will take effect, and tells you when an instruction would not have worked.

​
How WPOS changes store templates

Classic themes

WPOS stores its template customizations itself and renders them at runtime, so it never edits the theme’s files. Update or switch the theme and your customizations are unaffected.

Block themes

WooCommerce renders these stores from block templates, so WPOS edits the block template, the same way the Site Editor does. A PHP template override would not take effect there.

​
Conflict detection

Something else may already control the store template you want to change: Elementor Pro’s Theme Builder, Divi’s Theme Builder, or a block theme’s own WooCommerce templates. WPOS detects this and warns you, instead of making a change that would never show on the store.

​
What it looks like

In the video, WPOS restyles the product page of a small coffee store:
  • A larger product gallery, four trust badges under Add to cart, and related products in a four-column grid.
  • Every style is namespaced, so the store restyle cannot leak into the rest of the site.
  • A “ships in 2 to 3 days” notice for one product category, added as a snippet scoped to that category.
  • WPOS points out, unprompted, that it invented the badge copy and that it had not seen the page render yet, because the store was in coming-soon mode.
Before you publish, read any copy WPOS wrote for the store, such as delivery or returns promises, and check the page in the preview. The agent flags what it could not verify; the final check is yours.

Page builders

How WPOS works in Gutenberg, Elementor, and Divi, with no lock-in.

Styling and brand

Pin the brand so every page, including the store, stays on-brand.