Part 1: Building a Popup for FSE WordPress

Most WordPress popup plugins don’t play well with Full Site Editing. Here’s how I’ve started building a custom, block-editor-native popup solution that solves that.

None of the plugins I tried worked particularly with Full Site Editing (FSE). I wanted a solution that stayed fully within the block editor, without relying on custom post types or complex configuration. For something like a popup form, it didn’t make sense to push content into a separate post type — the content should live inline.

The First Attempt: A Single Block with Button + Popup Content

So, I created a custom popup content block. It included:

• A simple button, with the label set via a sidebar control (stored as a block attribute).
• A popup container that accepted any blocks inside it — including forms, images, etc.
• Some light JavaScript to show/hide the popup on button click.
• CSS transitions to fade and scale the popup into view.

Because the button and container were placed next to each other, the JavaScript could easily locate the matching popup. It was lightweight, tidy, and worked surprisingly well.

What Didn’t Work

But the more I used this primitive version of my popup, the more its limitations became clear:

1. No Support for Multiple Triggers

You could only trigger the popup from the button placed next to it. If you wanted a second button to trigger the same popup, you had to duplicate the content — leading to unnecessary page weight and maintenance overhead.

2. Why Rebuild the Button?

I had recreated a simplified version of the native WordPress Button block. But the core block already does everything I need (and more), including styling, accessibility, and responsive layout. Why introduce another button block with fewer features?

3. Awkward Layout in the Editor

In the editor, the popup container sat directly beneath the button. This was fine in simple layouts, but if you used the button inside a narrow column (like in a grid or hero layout), the full popup block sat awkwardly within that space, making editing more frustrating.

---

Rethinking It: Decoupling the Trigger from the Content

What I really needed was to decouple the popup trigger from the popup content:

• Use the native WordPress Button block as the trigger.
• Let multiple buttons point to a single popup container.
• Allow the popup container to be placed anywhere in the editor without affecting layout flow.

To do this, I updated my system so that:

• Any button with a specific CSS class (e.g. popup-trigger) and a matching rel attribute would trigger a popup with a matching id.
• The popup container block used that id to identify itself.
• The JavaScript handled showing/hiding the correct popup, no matter where it was placed in the DOM.

---

The Result ( or the new begining )

The final approach is:

• Block-editor native
• No jQuery
• Fully decoupled components
• Works with the existing Button block
• Lightweight and easy to maintain

Checkout the block’s github repository here, at time of writing I am at version 0.3.0 and intend to release a credible version 1 soon

I also intend to add a Docker Compose setup to make it easy to test locally. If you’re interested, follow along — a follow-up post will include setup instructions and usage examples.