WordPress Builder Limitations — Design Constraints

Overview

When working on client websites built with third-party WordPress page builders — particularly sites not hosted in Asymmetric's own environment — the team encounters recurring design and implementation constraints. These limitations can block or degrade the fidelity of approved designs and require workarounds or expectation-setting with clients and developers.

This article documents the specific constraints surfaced during the ^[1] project and generalizes them for future reference.

Known Constraints

Header Image Hover Behavior

WordPress page builders may not support precise control over image swap or hover-state behavior on header elements. On the Diddy project, the header image displayed the wrong photo on hover — a behavior caused by the builder's limited handling of hover states rather than a design or asset error.

"I used that one because when you scroll over the link to the website, it shows only this photo that I used."
— Michał Bielerzewski, ^[2]

Implication: Designers should verify hover-state behavior in the actual builder environment before finalizing specs. What is achievable in Figma may not map 1:1 to builder output.

Element Overlap / Layering

Third-party WordPress builders often restrict the ability to overlap elements (e.g., placing text or images over adjacent sections). This was flagged as a likely blocker on the Diddy project during development handoff.

"I know he's struggling with, like, I bet you he can't overlap it."
— Melissa Cusumano, ^[2]

Implication: Designs that rely on overlapping components should be flagged early. If the client's builder cannot support the layout, an alternative must be designed before development begins.

Header and Footer Inheritance

On sites not built or hosted by Asymmetric, the global header and footer are typically locked to the existing site's theme and cannot be freely redesigned. Any updates must conform to the constraints of the existing template.

Implication: Scope of work on third-party WordPress sites should explicitly note that header/footer changes may be limited or require theme-level access the team does not have.

Root Cause

These constraints arise specifically when:

The client owns and hosts their own WordPress site independently of Asymmetric's environment.
The site was built with a restrictive page builder (e.g., Elementor with locked templates, WPBakery, Divi, etc.) that limits CSS/HTML overrides.
Asymmetric does not have admin-level or theme-level access.

"We don't own that website. We don't have it in our environment. We didn't build it."
— Melissa Cusumano, ^[2]

Recommendations

Pre-project audit: Before designing for a client's existing WordPress site, confirm which builder is in use and what level of access the development team will have.
Design conservatively: Avoid layouts that depend on element overlap, custom hover states, or full header/footer redesigns unless builder capability is confirmed.
Flag early: If a design spec cannot be implemented in the client's builder, surface this during design review — not during development handoff.
Prefer Asymmetric-hosted environments: Where possible, advocate for migrating client sites to Asymmetric's environment to avoid these constraints entirely.

^[3]
^[4]
^[5]