bbioonThemes

Category: Gutenberg

  • Stop Fighting WordPress: Leverage Block Bindings Now

    A client hit me up last month. They needed a slick video section on their product pages—dynamic content, different video for each product, you know the drill. My first thought? Classic. Just spin up an ACF field, grab the URL, and manually inject it into the template. Easy, right? And yeah, that worked. For about five minutes, until they wanted more control, directly in the editor, without touching custom fields. Total nightmare, man. That’s when I realized: we keep doing things the old way, but WordPress is moving. Fast. Especially with features like Block Bindings becoming more flexible, sticking to old habits is just leaving power on the table.

    It’s already August, and the Roadmap to 6.9 is out. Evolution of the site editor, refining content creation, performance improvements—it’s all on the docket. This means the back half of 2025 is going to be a wild ride for us developers. If you’re not keeping up, you’re falling behind. Period.

    Expanding Core Blocks: More Tools, Less Hassle?

    For years, the stance on new core blocks felt pretty rigid. Anything deemed “too niche” was left to third-party plugins. And for a long time, that was fine. But blocks are different. Theme authors, myself included, need a robust toolkit right out of the box to build unique designs without forcing users into a plugin-chasing frenzy. Thankfully, it looks like this stance might be softening. Matías Ventura, the Gutenberg lead architect, recently put it plainly: not having these blocks in core “severely limits the expressiveness that theme builders (and users) can depend upon.” He’s right. Relying on external plugins for fundamental elements just fragments the experience. It makes sense, man. More blocks in core means more consistency and less reliance on external dependencies that can, let’s be honest, break things.

    Theme.json Control: A Developer’s Dream

    Another area seeing some serious traction is deeper control over the block editor’s UI/UX via theme.json. This isn’t just about styling anymore; it’s about defining the editing experience itself. We’re still a ways off from full feature parity here, but the standardization of Core blocks via the ToolsPanel component is a massive step. Imagine having the power to enable or disable specific inspector controls and toolbar options right from your theme.json. As a theme author, the possibilities are endless for crafting a truly bespoke and intuitive user experience. This level of granular control is a game-changer, trust me on this.

    Block Bindings: The Real Game-Changer

    Alright, enough with the “might happens.” Let’s talk about something concrete: Block Bindings. This is as close to a sure thing as it gets, and it’s been cooking on the WordPress Developer Blog for a while. With the latest WordPress trunk, you can now customize which blocks and attributes can be bound. Before, it was limited to Heading, Paragraph, and Button blocks. Now, with the new block_bindings_supported_attributes_{$block_type} filter hook, things are wide open.

    Remember that client with the dynamic video section? This filter is the answer. Instead of a custom field injection, we can bind the video source directly. I wasted no time tinkering with this once the patch landed in WordPress trunk. Making the Video block’s src attribute bindable? Oh, it’s sweet.

    <?php
add_filter( 'block_bindings_supported_attributes_core/video', 'devblog_bindable_video_attrs' );

function devblog_bindable_video_attrs( array $attrs ): array
{
	return array_merge( $attrs, [ 'src' ] );
}
?>

    This snippet? It’s all you need to open up the Video block for binding that src attribute. The beauty of this is that the user can pick their video, and if you’ve got a custom source, you can bind it up. Go check out the Block Bindings API tutorials on the Developer Blog for a deeper dive. The only problem I have with this feature is not having enough time to try out all the ideas I’ve had. Seriously. I’m going to have so much fun with this!

    Other Notable Shifts

    Beyond Block Bindings, there’s other crucial stuff happening. The Core AI team just published their AI Building Blocks for WordPress, outlining the PHP AI Client SDK, Abilities API, MCP Adapter, and AI Experiments Plugin. If AI integration is on your roadmap, you need to be in the #core-ai Slack channel. Also, the WordPress Coding Standards 3.2 release brings tighter checks and improved PHP 8.1+ support. No excuses for sloppy code now.

    On the data front, Data Views are getting a lot of attention with new fields, controls, operators, and grouping functionality. This is a big deal for custom admin screens and dynamic content listings. Plus, Playground CLI now defaults to PHP 8.3 and has Xdebug support. If you’re not using Playground for quick tests, you’re missing out. It’s a lifesaver. You can find more details on these updates directly on the Developer Blog, like the one found at https://developer.wordpress.org/news/2025/08/whats-new-for-developers-august-2025/.

    So, What’s the Point?

    The point is, WordPress isn’t standing still. The core team is actively pushing for a more robust, intuitive, and developer-friendly platform. Ignoring these advancements means you’re building with one hand tied behind your back. Embracing things like expanded core blocks, deeper theme.json control, and especially the evolving Block Bindings API means building sites that are more flexible, easier to manage, and ultimately, more future-proof. Don’t get stuck in the old ways; the new ways are better.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

  • WordPress Block Development: September’s Core Updates Deliver

    Just last week, a client hit me up. Their marketing team was wrestling with an existing page, trying to add some simple accordions and custom-styled form fields without breaking anything. The current setup? A total nightmare of custom JS and inline styles from an older theme. I looked at it and thought, “Man, this used to be a headache to implement properly, especially if you needed it accessible.” But here’s the kicker: WordPress core, especially with the September 2025 updates, is making this kind of stuff genuinely straightforward now.

    If you’ve been knee-deep in custom block development, or just trying to keep up with how WordPress is evolving, these updates are solid. They’re not flashy marketing buzz; they’re practical tools that make our jobs easier and client sites more robust. We’re talking about significant strides in core functionality that streamline development, reduce custom code, and ultimately, make sites more maintainable.

    Streamlining WordPress Block Development

    First up, the official “What’s new for developers?” September 2025 report on the WordPress Developer Blog highlights the new **Accordion block**. This has been a long time coming. We’ve all built countless custom accordion solutions, often fighting with accessibility standards (WCAG, USWDS) or patching things together with conflicting JavaScript. Now, WordPress gives us native Accordion, Accordion Item, Header, and Panel blocks, all powered by the Interactivity API. This means less custom code, better semantics out of the box, and a more consistent user experience. Trust me, rolling your own accessible accordion from scratch is not fun, and having this in core is a huge win for cleaner block development.

    Next, let’s talk about styling. Remember the days of fighting with global CSS overrides for basic form elements? It was messy. With the continued effort to allow `theme.json` to style form elements, you can now target text inputs, textareas, and even select/dropdown elements directly. This is massive for maintaining a consistent design system. You can centralize your form styling right in your theme’s `theme.json`, making it predictable and easy to manage without adding a bunch of extra CSS that conflicts everywhere. For example, to style your text inputs:

    "elements": {
	"textInput": {
		"border": {
			"radius": "0",
			"style": "solid",
			"width": "1px",
			"color": "red"
		},
		"color": {
			"text": "var(--wp--preset--color--theme-2)"
		},
		"typography": {
			"fontFamily": "var(--wp--preset--font-family--inter)"
		}
	}
}

    This kind of control, right from `theme.json`, removes a ton of boilerplate and ensures your styles are applied universally. It’s what we always wanted for true block themes, and it’s finally here.

    Beyond styling, the `@wordpress/create-block` package now allows block variants to define their own template files. If you’ve ever built complex blocks with many variations, you know the pain of conditional logic within a single template. This update simplifies managing those templates significantly. It’s a small change, but it makes a huge difference in the long-term maintainability of your custom blocks.

    And speaking of foundational work, the **Abilities API** is getting a Composer package and the PHP AI Client saw its first stable release. For those integrating advanced permissions or dabbling with AI in WordPress, this is the groundwork being laid. It means a more structured and official way to extend core functionality, rather than relying on custom solutions that might break with every major update.

    So, What’s the Point?

    The takeaway here is clear: WordPress core development is moving fast, and in the right direction. These aren’t just minor tweaks; they are foundational improvements that empower developers to build better, more maintainable, and more compliant sites with less effort. Leveraging these core features means fewer custom hacks, less technical debt, and more time focusing on what really matters for your clients.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

  • Extending WordPress Navigation Blocks with Custom Content

    I recently had a client come to me, pulling their hair out over a seemingly simple request: they wanted to drop a custom “mini-cart” block directly into their main navigation menu. Sounds straightforward, right? Well, not so fast. WordPress’s Navigation block, by default, is pretty particular about what it lets you put in there. It’s a total pain when you’re trying to achieve something beyond the standard link, and frankly, it kills a lot of creative menu ideas. They’d tried to force it with some dodgy CSS, and it was, as you can imagine, a complete mess in the editor, sometimes breaking the whole layout on certain screen sizes. That’s when we needed to talk about Extending Navigation Blocks the right way.

    The core of the problem is that the Navigation block is built to be a navigation tool, not a free-form content area. This is generally good for stability, but when you need to integrate custom functionalities – like a dynamic cart summary, a login form, or even a simple image – you hit a brick wall. My first thought, before really digging in, was to just tell them to live with it, or maybe try to inject the block content via some elaborate JavaScript after the page loads. But that’s a fragile, client-unfriendly solution that makes future maintenance a nightmare. It’s an editor problem, and it needed an editor-level fix.

    Extending Navigation Blocks: The Proper Hook

    The real fix lies in understanding how Gutenberg registers and manages blocks. Specifically, we need to tap into the blocks.registerBlockType filter to extend the allowedBlocks property of the core/navigation block. This isn’t just a hack; it’s a built-in WordPress mechanism for extending block functionality. The key here is to enqueue your custom JavaScript file using the enqueue_block_editor_assets hook, ensuring your script loads where it needs to: the block editor. This approach lets you tell the editor, “Hey, this navigation block? It can also handle this other block type now.” It’s clean, it’s maintainable, and it actually works within the editor.

    add_action( 'enqueue_block_editor_assets', function() {
    wp_enqueue_script(
        'my-agency-extend-navigation-script',
        plugins_url( 'js/editor-script.js', __FILE__ ),
        array( 'wp-hooks', 'wp-blocks' ), // Dependencies for block filters.
        '1.0.0',
        true
    );
} );

    Once that PHP snippet is in place, you need the JavaScript. Create an editor-script.js file inside a js folder within your plugin (or theme, if you know what you’re doing, but plugins are usually better for this kind of functionality). This script will then hook into the blocks.registerBlockType filter. You can see a great example of this over at developer.wordpress.org, which provided the foundation for this method.

    const addToNavigation = ( blockSettings, blockName ) => {
	if ( blockName === 'core/navigation' ) {
		return {
			...blockSettings,
			allowedBlocks: [
				...( blockSettings.allowedBlocks ?? [] ),
				'core/image', // Replace with your custom block or desired core block, e.g., 'my-plugin/mini-cart'
			],
		};
	}
	return blockSettings;
};

wp.hooks.addFilter(
	'blocks.registerBlockType',
	'my-agency-add-block-to-navigation',
	addToNavigation
);

    See that 'core/image' part? That’s where you’d drop the name of whatever block you need to add. For my client, it would have been their custom mini-cart block. This snippet tells the Navigation block, “Hey, you can also accept images now.” Or, in a real-world scenario, “You can accept my custom mega menu block,” or “my user profile widget.” It opens up the Navigation block to any block you define, without breaking anything. This is the solid, robust way to manage custom requirements within the block editor, especially when dealing with core blocks that have strict allowedBlocks definitions. Trust me on this, trying to hack around these limitations will bite you later.

    So, What’s the Point?

    The lesson here is simple: don’t fight the editor. When WordPress gives you hooks and filters, use them. Trying to force square pegs into round holes with CSS or sketchy JavaScript injections for editor functionality is a total nightmare for anyone who has to maintain the site later. This method for extending navigation blocks might seem like a few extra lines of code, but it provides a stable, forward-compatible solution that makes both your life and your client’s life much easier. It ensures custom elements can live gracefully within the navigation, exactly as intended.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.