The highly anticipated debut of WordPress 7.0 RC1 has been officially pushed back to March 24, as core developers struggle with unresolved questions regarding real-time collaboration and the removal of heavy media features.
In a decisive move this Thursday, the WordPress release squad voted to postpone the first release candidate by five days, a shift that includes the total removal of client-side media processing and a major reversal on default settings for collaborative editing.
The rescheduled RC1 release event is now set for March 24 at 3pm UTC, though leadership confirmed that the final launch date of April 9 – which aligns with WordCamp Asia 2026 Contributor Day – remains firmly in place.
Release coordinator Amy Kamala announced the new timeline on Make WordPress Core, citing three critical bottlenecks that forced the team’s hand: real-time collaboration (RTC) performance, slow client-side image optimization, and a significant surge in the overall package size.
RELATED DEVELOPMENTS
- Ongoing Debates Surrounding Real-Time Sync in WordPress 7.0
- Proposals for AI Integration Spark Controversy Ahead of Core Merge
- WordPress 7.0 Beta 1 Launches Following Leadership Realignment
Tensions had been simmering throughout Thursday in the WordPress Slack #core channel, where committers and squad members spent hours debating whether the release was truly ready for the RC1 milestone while the original deadline passed by.
Matias Ventura, the project’s release lead, eventually proposed a revised roadmap that includes an additional beta release over the coming weekend to address the most pressing concerns.
“Yes, there’s been solid feedback on RTC and client-side image optimization that we need to account for,” Ventura wrote in a Slack update. “Really appreciate the engagement from everyone helping make this an awesome release.”
Real-Time Sync Strategy Shifts and Default Settings Reversal
Earlier in the week, news broke that a team of contributors, headed by Peter Wilson, was developing a dedicated database table designed to fix persistent cache invalidation issues inherent in real-time syncing.
This technical fix aimed to migrate RTC sync data completely out of post meta, ensuring that users with an active editor window would not inadvertently disable the platform’s vital post query caches.
Matt Mullenweg had previously offered his qualified support for the new database table, but that specific architectural path has now been sidelined for the 7.0 release cycle.
On Monday, tech lead Ella Van Durpe raised alarms on the project’s Trac ticket regarding the risks of adding a database table so late in development, offering an alternative fix that modifies the meta registration API instead.
The situation took a turn on Thursday when contributor Max Schmeling announced that the decision had been made to drop the table entirely, a move that reportedly blindsided Wilson and several other active developers.
“All of the hard work on it to this point is very much appreciated, and we definitely are going to want to continue to validate it for the 7.1 cycle,” Schmeling explained, noting that the urgency had decreased thanks to Van Durpe’s alternative fix.
Wilson’s reaction to the news was immediate and critical, expressing disappointment that those actually building the schema were excluded from the final decision-making process involving Automattic-sponsored leads.
Supported by independent committer David Baumwald, Wilson argued that the release schedule was now dictating the quality of the implementation, potentially sacrificing architectural integrity for the sake of meeting a deadline.
Lynn Bradley Griffith defended the pivot, stating that a review by the Systems team suggested that the risks of getting a new schema right this late in the game were simply too high for a major release.
Wilson remained vocal in his disagreement, asserting that rushing complex changes to fundamental APIs like WP_Query is a far more dangerous gamble for the WordPress ecosystem in the long run.
The developer has since provided a different patch – one that defers cache invalidation – and suggested that if the only other choice is a rushed core API change, the RTC feature should remain in the Gutenberg plugin for further maturation.
Meanwhile, Anne McCarthy confirmed on Wednesday that real-time collaboration will no longer be active by default in the RC1 build, moving instead to an opt-in toggle within the Writing settings.
This change means that any users who had the feature enabled during the beta phase will find it turned off upon upgrading, as the underlying option names have been modified to reflect the new default state.
“While more time was wanted to test more broadly, it’s increasingly become clear that it is better to make the call now rather than later on in the cycle,” McCarthy stated, acknowledging the value of the beta feedback.
Ventura clarified that while 7.0 will launch with the feature set to opt-in, the goal remains to transition to an opt-out model by version 7.1 once more robust hosting and plugin coverage is achieved.
Client-Side Media Processing Deferred to WordPress 7.1
In another major blow to the 7.0 feature list, client-side media processing has been officially removed from the release and rescheduled for version 7.1.
The feature was intended to utilize WebAssembly and the libvips library to handle resizing and compression directly in the user’s browser, but performance benchmarks this week showed disappointing results.
Sérgio Gomes, an Automattic performance engineer, reported that the process was significantly slower than expected, with JPEGs taking 19 seconds and AVIF files taking nearly a minute to process on an M4 Pro laptop.
Gomes highlighted that comparable tools like Squoosh manage the same tasks in under 3 seconds, while also reporting that the current WordPress implementation suffered from memory crashes and various console errors.
Beyond speed issues, Ella Van Durpe and Matias Ventura pointed out that the feature was currently limited to Chromium-based browsers and suffered from a fragmented user experience during the upload process.
The footprint of the library was also a major concern, as Adam Silverstein noted that libvips added about 13MB to the WordPress package, contributing significantly to a recent spike in total build size.
As the debate in Slack came to a close on Thursday, Silverstein submitted a pull request to excise the feature from the 7.0 codebase, noting that he was comfortable with either outcome.
“I do feel the build size change for adding vips is expected and worth it which will be more apparent by 7.1 though when we can add some additional features like UltraHDR support,” Silverstein wrote.
Package Bloat and the Struggle for Optimization
Even with the removal of the 13MB media library, WordPress 7.0 continues to face a significant “size problem” that contributors are racing to address before next Tuesday.
The current uncompressed nightly build has swelled to approximately 60MB, a massive increase compared to the 27MB footprint seen in version 6.9.4.
Analysis provided by Adam Zieliński and Ella Van Durpe on the Trac ticket pointed to several culprits, including 5.5MB of new admin routing files and redundant block-specific CSS directories.
While committer Jonathan Desrosiers worked on Thursday to remove orphaned files that had been accidentally included in the package, the total size of the build did not decrease as much as hoped.
Silverstein argued that some growth is inevitable for a release that adds major functionality, comparing WordPress’s footprint to a fresh Drupal installation, which typically weighs in at around 156MB uncompressed.
