WordPress 7.0 development: a new toolkit and a privacy gap

The dev chat agenda for WordPress 7.0 development is out, and it pairs some genuinely useful tooling with a reminder that core components can sit and gather dust. Heading into the April 22 meeting, the question has moved from which features go in to how the thing gets built at all.

In 14 years around WordPress I have watched release schedules slip more times than I can count, so I read roadmaps with some suspicion. This one is at least pointed somewhere different: at how contributing works, rather than at the code. If you have followed the delays in WordPress 7.0 development, you already know stabilizing core comes ahead of everything else right now.

Scaling WordPress 7.0 development with the new toolkit

The main announcement is the WordPress Core Dev Environment Toolkit. Anyone who has set up wordpress-develop locally knows the routine: Docker refuses to cooperate, Node is on the wrong version, and something works on your machine and nowhere else. The toolkit is a desktop application for macOS, Windows and Linux, and it exists mostly so that afternoon stops happening to new contributors.

Setup is one click, with the npm install and environment provisioning handled in the background. If you run an agency, that is the difference between a junior dev filing a first core patch and a junior dev losing a full day to environment debugging.

The privacy maintenance gap

A rougher item on the agenda is the #core-privacy channel, which currently has nobody maintaining it. That is a bad place to be going into a major release. @masteradhoc has volunteered, though the backlog is deep: PRs #11442 and #11444 both need review now rather than later.

An unmaintained privacy component puts the legacy hooks for data export and erasure at risk. Here is how the exporter side works, which is usually where the performance problems turn up:

<?php
/**
 * Example of a privacy data exporter hook.
 * This is the type of logic being refactored in WordPress 7.0 development.
 */
function bbioon_register_privacy_exporter( $exporters ) {
	$exporters['my-custom-plugin'] = array(
		'exporter_friendly_name' => __( 'Custom Plugin Data' ),
		'callback'               => 'bbioon_custom_data_exporter',
	);
	return $exporters;
}
add_filter( 'wp_privacy_personal_data_exporters', 'bbioon_register_privacy_exporter' );

function bbioon_custom_data_exporter( $email_address, $page = 1 ) {
	// The PRs in question are addressing how $page handles large datasets
	// to avoid memory exhaustion during the export process.
	$data_to_export = array();
	// ... logic to fetch data safely ...
	return array(
		'data' => $data_to_export,
		'done' => true,
	);
}

What’s next for the roadmap?

A new release schedule for 7.0 is expected this week. After the trunk closure and RTC pivots, the core team needs to put a real timeline in front of people. The “Path Forward” document published earlier this month points to a more conservative line on new features until the existing component maintenance is handled.

If keeping up with the 7.0 cycle is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days.

Final takeaway

The April 22 dev chat should show which way the 7.0 cycle goes. If people pick up the toolkit and fill the privacy maintenance gap, the timeline has a chance. If not, expect more “Path Forward” updates and less shipped code. The PRs themselves are covered on the official Make WordPress blog and in the related Trac tickets.

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.