Earlier this year, an attempt to streamline how WordPress syncs code from the Gutenberg plugin into the core codebase ended up causing significant problems for contributors — including broken integrations, missing file minification, and the complete loss of version history for a set of shared PHP files. After months of careful planning, testing, and iteration, the WordPress core team has restored those files and reconnected their history through a novel approach that had never been used in the project before.
The trouble began with changeset [61438], committed on January 5, 2026. The change removed a group of PHP files from version control and added them to .gitignore, intending Gutenberg’s repository to serve as the single source of truth. Instead, it triggered a series of downstream failures. The distributed hosting test suite broke, several files stopped being minified correctly, and — critically — git-based tools including IDEs and GitHub’s own interface could no longer see or track changes to the affected files. Tracing the affected files’ history across the 800-plus commits between WordPress 6.8.5 and 6.9.0 — now unavailable to version control directly — added over nine hours of runtime to certain contributor workflows even after optimizations.
A straightforward revert would have brought the files back, but would have made them appear as brand-new additions with no prior history. The team instead pursued a more complex solution: building a restore branch from the revision just before [61438], then merging it back into trunk — a type of reintegration merge that had never been done in the WordPress codebase. The side-effects of the original change that needed addressing included:
- Boot-sequence failures caused by WordPress calling
requiredirectly on files that no longer existed in version control - Files that stopped being minified by the build script
- Version history severed, making files appear to have no prior existence in the repository
- Removed files persisting on the build server and shipping unintentionally in beta and RC releases
- Changes to
.gitignorehiding accidental edits to core files, creating a false sense of safety
The restore branch was built so that each commit corresponds to a Gutenberg sync commit in the main trunk branch, reconstructing the history that would have existed had the files never been removed. This granularity means a developer investigating a regression in early 2026 can now trace exactly which Gutenberg sync introduced the change, rather than scanning through hundreds of unrelated commits.
The execution required two parallel simulation scripts — one for git, one for SVN (Subversion, the version control system that still underpins all official WordPress code). A test copy of the develop.wordpress.org Subversion repository was provided by contributor @abbe for verification. It took fifteen full iterations of the simulated branch creation before the output matched expectations precisely. The goalpost throughout was that after merging, the automated build bot would produce zero follow-up commits — meaning no files had been changed by the build, confirming the restore was complete and correct.
Even with that preparation, the live deployment hit a snag: a fatal Grunt error stalled the build server during commit processing, requiring contributor @aidvu to manually clear it. Once resolved, a single run of the script was enough to complete the restoration successfully in the months following the original break. The WordPress core team has documented the full recap as a cautionary example of how deeply fundamental changes to WordPress development infrastructure can ripple across contributor workflows.
