WordPress 7.0 roadmap: what beta 5 and RC1 actually change

WordPress 7.0 is close, and if you have not been following the WordPress 7.0 Roadmap, now is the time. We are in the pencils down phase. Beta 5 landed last week, Release Candidate 1 is on track for tomorrow, and the technical foundation is set. I have shipped through enough major releases to know this is the point where the debugging starts in earnest for anyone maintaining high-traffic client sites.

From beta 5 to RC1

The move from beta to RC is always a scramble. Beta 5, released on March 12th, mostly polished the rough edges of the new block-binding integrations. Once RC1 lands, the WordPress 7.0 Roadmap is done with new features and turns to stability. If your custom blocks or deep theme hierarchies have not been tested against the latest core changes by tomorrow, you are gambling with your May deployments.

Pattern overrides now cover custom blocks

The pattern overrides update is the biggest shift here for agencies. Overrides used to be limited to core blocks. Custom blocks are now supported, so you can build a design system where one Hero pattern stays synced across 50 pages while the call to action text on each page survives. It runs on the Block Bindings API, which connects the global design to the local content.

<?php
/**
 * Registering support for pattern overrides in a custom block.
 * This allows specific attributes to be overridden within a synced pattern.
 */
function bbioon_register_pattern_override_support() {
    register_block_type( 'bbioon/custom-cta', array(
        'supports' => array(
            'patternOverrides' => true,
        ),
        'attributes' => array(
            'content' => array(
                'type' => 'string',
                'source' => 'html',
                'selector' => '.cta-text',
                'role' => 'content', // Critical for pattern overrides
            ),
        ),
    ) );
}
add_action( 'init', 'bbioon_register_pattern_override_support' );

Native viewport controls

We have faked this for years with CSS classes like .hide-on-mobile. WordPress 7.0 brings Block Visibility by viewport into core, which gives conditional rendering a standard home instead of another pile of theme CSS. If you are running a third-party plugin for visibility logic, audit the site and see how much of it the native controls can replace.

Custom CSS and the tech debt it invites

One item on the WordPress 7.0 Roadmap gives me pause: Custom CSS for individual block instances. Handy for a quick fix, painful to maintain a year later. I would rather push everything through theme.json presets. Let clients drop raw CSS into the block inspector and you will be debugging specificity fights six months from now. Use it sparingly, or disable the UI in client builds.

If this WordPress 7.0 Roadmap work is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.

The road to May 20th

The next few weeks decide what actually ships. The March 18th Dev Chat covers these final releases. Core is also moving toward a standardized AI setup through the Connectors API, along with finer block controls. My advice: pull the latest from WordPress News, spin up a staging site, and break things there instead of on launch day.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.