Coder Legion - Recent posts tagged gutenberg

Quovex Blocks: A Post Grid, Featured Posts and Announcement Bar Built on the Interactivity API

Thu, 08 Oct 2026 10:37:36 +0000

Most WordPress sites end up needing the same few things: a grid of recent posts, a featured section on the homepage, and a banner for announcements. The usual answer is a page builder or a stack of separate plugins, each bringing its own UI and its own frontend scripts.

Quovex Blocks is a free WordPress plugin that does all three as native Gutenberg blocks, with the frontend interactivity running on the WordPress Interactivity API instead of jQuery.

▶️ Watch the 2-minute demo: https://youtu.be/ADyo0WuhiR0

The three blocks

Query Grid

A filterable, paginated grid that works with any public post type: Posts, Pages, WooCommerce products or your own custom post types.

Grid, List, Masonry and Carousel layouts
Search bar and taxonomy filter pills (multi-select within a taxonomy), optionally in a left or right sidebar
Numbered pagination or a "Load more" button, plus a "Show all posts" toggle
Responsive column counts, plus color and typography controls that use your theme's fonts

Content Showcase

A magazine-style section for up to three posts.

Magazine, Split, Overlay and Two-Thirds/One-Third layouts
Automatic mode (latest posts, optionally filtered by taxonomy) or manual mode (hand-pick a post for each slot)
Image hotspots: pins you place on a post's image, each opening a popover with its own title, text and link

A dismissible announcement bar or inline alert.

Announcement, Info, Success and Warning presets, with five style variations
Emoji, dashicon or SVG icon picker, and an optional call-to-action button
Dismissal is remembered in the visitor's browser, so a closed banner stays hidden on their next visit

How it's built

Dynamic blocks + the Interactivity API

Query Grid and Content Showcase are dynamic blocks rendered in PHP through render.php, so the first paint is plain server-rendered HTML. Frontend behavior (search, filters, pagination, the carousel and hotspots) is attached with the Interactivity API through a viewScriptModule, so it ships as a script module and no jQuery or other framework is loaded.

Here's the relevant part of Query Grid's block.json:

{
  "apiVersion": 3,
  "name": "quovex-blocks/query-grid",
  "render": "file:./render.php",
  "viewScriptModule": "file:./view.js",
  "supports": {
    "interactivity": true
  }
}

Pagination that search engines can follow

Clicking a page number swaps in the new results without a full page reload, but the address bar updates to a real URL, and opening that URL directly server-renders the correct page. So visitors get instant navigation, and crawlers still get normal, followable links. The pagination URL segment is configurable (for example /your-site/quovex-page/2/) as a site-wide setting.

Layouts as style variations

Every layout is a native block style variation. Switching from Grid to Masonry, or from Magazine to Overlay, is one click in the editor's Styles panel, with no custom layout picker to learn.

A cache that invalidates itself

Query results are cached and cleared automatically the moment a post, category or tag changes, so repeat visits stay fast without serving stale content. Nothing is loaded on pages that don't use the blocks.

Clean uninstall

Deactivating leaves everything in place in case you come back. Deleting the plugin runs uninstall.php, which removes every option and cached value the plugin created.

Tooling

Built with @wordpress/scripts using --experimental-modules and --blocks-manifest
PHP classes autoloaded via PSR-4, with a built-in fallback loader so the shipped plugin needs no vendor/ folder
PHPUnit tests, PHPCS and ESLint, with Husky pre-commit hooks
GitHub Actions for CI, and a workflow that deploys new tags to WordPress.org

Try it

The plugin is free on WordPress.org. In your dashboard, go to Plugins → Add New and search for "Quovex Blocks".

Plugin: https://wordpress.org/plugins/quovex-blocks/
Source: https://github.com/akshat009/quovex-blocks

Feedback and issues are welcome on GitHub, and a review on WordPress.org helps other people find it.

I'm Akshat Saxena, a Senior WordPress Developer with 8+ years in WordPress, working across WooCommerce, Gutenberg/FSE and custom plugins. If you're looking for someone to build or extend a WordPress product, feel free to reach out on LinkedIn.

A Gutenberg block that uses the Interactivity API — with no render callback and no framework on the front end

Sun, 20 Sep 2026 05:18:15 +0000

A YouTube embed looks innocent enough.

You drop an iframe into a page, give it a src, and you're done, right?

Except you're not.

Google's Lighthouse documentation puts a full embedded YouTube player at around 540 KB. On a live page, it's closer to 1.3 MB. And the cost doesn't get amortized when you add another embed — two players can mean roughly twice the payload because the resources aren't shared.

HTTP Archive data referenced by web.dev puts another horrifying metric on it: the median YouTube embed occupies the browser's main thread for more than 1.7 seconds.

And here's the part that bothered me most: All of that happens even if nobody presses Play.

The Solution: The Facade Pattern

The fix isn't new. It's the facade pattern:

Show a poster.
Show a play button.
Don't load the actual player.
Only load it when the visitor clicks.

Tools like lite-youtube-embed have been doing this for years.

I wanted to bring this exact same concept into a WordPress Gutenberg block—but not just for YouTube, and definitely not by shipping an entire JavaScript framework to the browser just to replace a JPEG with an iframe.

That experiment became the Story Video Block (now live on the WP repo, source on GitHub).

Here are the most interesting architectural decisions and technical gotchas I ran into while building it.

The Interactivity Dilemma

The actual interaction needed for a facade is tiny. Click. Swap in the embed. Play the video. That's basically it.

But traditional block solutions can be surprisingly expensive for such a small interaction:

You could enqueue a classic view.js and manually handle event delegation and DOM manipulation.
You could ship React to the front end (some block plugins actually do this). You're essentially sending a UI framework to someone's phone so a poster image can turn into an iframe.
You could use jQuery (please don't).

Enter WordPress's Interactivity API ⚡

Since WordPress 6.5, we have the Interactivity API. It gives blocks a declarative way to add client-side behavior. More importantly, the runtime is shared by all blocks on the page.

The opt-in is incredibly simple in your block.json:

"editorScript": "file:./index.js",
"style": "file:./style-index.css",
"viewScriptModule": "file:./view.js"

Notice one detail: viewScriptModule, not viewScript.
That registers the file through the Script Modules API and allows you to natively import the shared WP runtime:

import { store } from '@wordpress/interactivity';

Revelation: You Don't Need a Dynamic Block

This was my biggest misconception. Because almost every Interactivity API tutorial uses a dynamic block (render.php), I assumed they were mandatory. They aren't.

The directives are just HTML attributes. A static block's save() function can output them, and the frontend runtime will hydrate whatever it finds.

Here's how my static save() looks:

const blockProps = useBlockProps.save( {
	className: clsx( {
		[ `has-media-${ videoPosition }` ]: videoPosition,
		[ `card-style-${ cardStyle }` ]: cardStyle,
	} ),
	style: {
		'--story-video-block-bg': backgroundColor || undefined,
	},
	...( ! isFile
		? {
				'data-wp-interactive': 'create-block/story-video-block',
				'data-wp-context': JSON.stringify( {
					isPlaying: false,
					embedUrl,
					videoSrc: '',
				} ),
		  }
		: {} ),
} );

That JSON.stringify() is the whole server-state story for this block! The markup lives in post_content. There's no PHP render callback running on every request, yet each block instance gets its own scoped, reactive state.

The Performance Trick: The `iframe` with no `src`

You cannot render an iframe and just CSS hide it. If it has a src, the browser will load the player. Hidden doesn't mean unloaded.

So, the iframe is deliberately rendered without a src.

<div
	className="story-video-block__video"
	hidden
	data-wp-bind--hidden="state.isNotPlaying"
>
	<iframe
		title={ heading || __( 'Video', 'story-video-block' ) }
		data-wp-bind--src="context.videoSrc"
		allow="autoplay; fullscreen; picture-in-picture"
		allowFullScreen
	/>
</div>

Initially, context.videoSrc === ''. Because WP's data-wp-bind--* removes an attribute when its value is falsy, there is no src attribute at all. No request, no player.

Bonus UX win: Because the source is assigned inside the click handler, the browser treats playback as user-initiated. That means autoplay=1 actually works. One click, video starts. No double-clicking required.

Progressive Enhancement: The facade is a link

I didn't make the facade a <div>. JavaScript shouldn't be the only way to reach the video.

The facade is a real <a> tag pointing to the original video:

<a
	href={ videoUrl }
	target="_blank"
	rel="noopener noreferrer"
	className="story-video-block__facade"
	data-wp-on--click="actions.play"
	data-wp-bind--hidden="state.isPlaying"
>

Our Interactivity store then enhances it:

import { store, getContext } from '@wordpress/interactivity';

store( 'create-block/story-video-block', {
	state: {
		get isPlaying() { return getContext().isPlaying; },
		get isNotPlaying() { return ! getContext().isPlaying; },
	},
	actions: {
		play( event ) {
			const context = getContext();
			if ( context.isPlaying ) return;

			// If no direct-embed URL (like TikTok), let the original <a> link work!
			if ( ! context.embedUrl ) return;

			event.preventDefault();
			context.videoSrc = context.embedUrl;
			context.isPlaying = true;
		},
	},
} );

This gives us graceful degradation:

JS + Supported provider (YouTube/Vimeo): Plays inline seamlessly.
JS + No direct embed (TikTok): Acts as a normal link.
No JS enabled: Acts as a normal link.

A CSS Gotcha That Cost Me an Evening

The Interactivity API was working. The hidden attribute was toggling perfectly in the DOM. But the elements were still visible on the screen. Why?

Browsers have a default user-agent style:

[hidden] { display: none; }

But if your block's custom CSS applies an explicit display (like display: flex;), it overrides the low-specificity [hidden] rule.

The fix:

[hidden] {
	display: none !important;
}

Pro-tip: If you're using data-wp-bind--hidden and nothing is happening visually, check your CSS specificity before ripping apart your JavaScript!

Why skip WordPress oEmbed on the frontend?

WordPress has robust oEmbed support. Why did I write manual regex provider detection for the frontend?

Because the /oembed/1.0/proxy endpoint requires edit_posts permissions. An anonymous site visitor gets a 401 Unauthorized.

Instead, the block parses the URL itself (supporting YouTube, Vimeo, Dailymotion, Twitch, mp4s, etc.) and constructs the embed URL string locally. Zero network requests just to figure out a URL we already know how to build.

Final Thoughts

Building this reminded me of a golden rule in web development: Don't make every visitor pay for a feature that only some visitors will use.

A video doesn't need to be a 1MB+ third-party application just because someone might press Play. A static Gutenberg block doesn't need to become dynamic just to hold state. And a tiny bit of interactivity doesn't require shipping a massive JS runtime.

If you're building blocks for WordPress, give the Interactivity API a shot for your next frontend component!

The Story Video Block is currently v0.1.0, requires WP 6.8+, and is GPL. If you want to check out the full code or contribute, PRs are welcome on GitHub!