{"id":122418,"date":"2026-06-17T18:53:06","date_gmt":"2026-06-17T18:53:06","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=122418"},"modified":"2026-06-17T18:53:06","modified_gmt":"2026-06-17T18:53:06","slug":"recap-restoring-removed-version-history","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/06\/17\/recap-restoring-removed-version-history\/","title":{"rendered":"Recap: Restoring removed version history."},"content":{"rendered":"<p class=\"wp-block-paragraph\">Since the <span tabindex='0' class='glossary-item-container'>block<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Block<\/span> <span class='glossary-item-description'>Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.<\/span><\/span><\/span> editor was first merged into <code>wordpress\/wordpress-develop<\/code> (leading up to the WordPress 5.0 release), there has always been a considerable amount of manual work required to sync the necessary changes in the <code>gutenberg<\/code> <span tabindex='0' class='glossary-item-container'>GitHub<span class='glossary-item-hidden-content'><span class='glossary-item-header'>GitHub<\/span> <span class='glossary-item-description'>GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the \u2018pull request\u2019 where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. <a href=\"https:\/\/github.com\/\">https:\/\/github.com\/<\/a><\/span><\/span><\/span> repository into <span tabindex='0' class='glossary-item-container'>SVN<span class='glossary-item-hidden-content'><span class='glossary-item-header'>SVN<\/span> <span class='glossary-item-description'>Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.<\/span><\/span><\/span>. During the early phases of the 7.0 release cycle, <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64393\">#64393<\/a> worked on making changes to the <code>wordpress-develop<\/code> build scripts with the goal of simplifying this process.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">While the initial iteration of these changes committed in <a href=\"https:\/\/core.trac.wordpress.org\/changeset\/61438\">[61438]<\/a> removed some of that manual friction, specific parts of the change disrupted a few important contributor workflows due to the way that <span tabindex='0' class='glossary-item-container'>PHP<span class='glossary-item-hidden-content'><span class='glossary-item-header'>PHP<\/span> <span class='glossary-item-description'>The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher<\/span><\/span><\/span> files were removed from <span tabindex='0' class='glossary-item-container'>version control<span class='glossary-item-hidden-content'><span class='glossary-item-header'>version control<\/span> <span class='glossary-item-description'>A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories.<\/span><\/span><\/span> and added to the <code>.gitignore<\/code> file. These particular PHP files were shared in both repositories, and the idea of removing them was to ensure that the source of truth remains clearly in the <span tabindex='0' class='glossary-item-container'>Gutenberg<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Gutenberg<\/span> <span class='glossary-item-description'>The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.\r<a href=\"https:\/\/wordpress.org\/gutenberg\/\">https:\/\/wordpress.org\/gutenberg\/<\/a><\/span><\/span><\/span> repository. Instead of existing in both repositories, a script would create the files in the working copy of the <code>wordpress\/wordpress-develop<\/code> repo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What went wrong?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Unfortunately, there were a number of unanticipated side-effects of this change:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A number of existing integrations started failing where the build script was not run due to the fact that WordPress calls <code>require<\/code> directly on these files to load them. This included <a href=\"https:\/\/make.wordpress.org\/hosting\/test-results\/\">the distributed hosting tests<\/a>.<\/li>\n\n\n\n<li>Several files that were previously minified by the build script no longer were (see <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/65007\">#65007<\/a>, <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64909\">#64909<\/a>)<\/li>\n\n\n\n<li>While the source of truth of these files lives in Gutenberg, it\u2019s valuable to know when the updates were brought into <span tabindex='0' class='glossary-item-container'>Core<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Core<\/span> <span class='glossary-item-description'>Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span> and what those updates were. Development in the Gutenberg <span tabindex='0' class='glossary-item-container'>plugin<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Plugin<\/span> <span class='glossary-item-description'>A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory <a href=\"https:\/\/wordpress.org\/plugins\/\">https:\/\/wordpress.org\/plugins\/<\/a> or can be cost-based plugin from a third-party.<\/span><\/span><\/span> runs at a different pace than in Core, which means that diagnosing changes to these files from the Gutenberg side is considerably more difficult and time-consuming than when there are changes in version control, which provide pins for when defects are introduced or resolved.<\/li>\n\n\n\n<li>Technically, there was a dual source of truth for these files before the change. The ultimate copies which made it into a WordPress release were those which had been committed into SVN, while the Gutenberg plugin might ship changed or updated files. After the change, that \u201cultimate\u201d copy no longer existed in SVN, except in the final release bundles. The \u201csource of truth\u201d for the files in both contexts (WordPress and the Gutenberg plugin) lived solely in Gutenberg, but might actually be different from each other due to the new commit hash pinning in <code>wordpress-develop<\/code>.<\/li>\n\n\n\n<li>Because these files were removed and the change added this new requirement to run the build step, major delays were introduced to any workflow which steps through commits. Even after a series of optimizations, this added over nine hours of runtime just to walk the 800+ commits from 6.8.5 to 6.9.0.<\/li>\n\n\n\n<li>Version history for these files was severed in the change, making it suddenly look like the files were never part of the repository. Any attempts to review the history required custom <code>git<\/code> commands not usually available in IDEs or GitHub\u2019s <span tabindex='0' class='glossary-item-container'>UI<span class='glossary-item-hidden-content'><span class='glossary-item-header'>UI<\/span> <span class='glossary-item-description'>User interface<\/span><\/span><\/span>.<\/li>\n\n\n\n<li>Files that were removed from version control were abandoned on the build server, which did not clean up properly. This resulted in removed files persisting and being included unintentionally in the <span tabindex='0' class='glossary-item-container'>beta<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Beta<\/span> <span class='glossary-item-description'>A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.<\/span><\/span><\/span> and <span tabindex='0' class='glossary-item-container'>RC<span class='glossary-item-hidden-content'><span class='glossary-item-header'>release candidate<\/span> <span class='glossary-item-description'>One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see <a href=\"#alpha-beta\">alpha (beta)<\/a>.<\/span><\/span><\/span> versions (see <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64716\">#64716<\/a> and <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/65418\">#65418<\/a>).<\/li>\n\n\n\n<li>While it happens from time to time that someone accidentally updates the code in one of these files in the Core repository instead of in Gutenberg where it should be done, the <code>.gitignore<\/code> directives <em>hide<\/em> any of those accidental changes, frustrating an already confusing situation. All <code>git<\/code>-based tooling (IDEs, <code>git<\/code>, <code>git <\/code>GUIs, linters, etc\u2026) is unable to see or revert changes to these files, giving a false sense of safety when someone checks in code that will unexpectedly fail once running on a different computer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What was resolved?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Two fundamental problems needed to be resolved:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Files that are required by WordPress\u2019 boot sequence needed to be restored.<\/li>\n\n\n\n<li>The version history continuity for these files would ideally need to restored.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">On one hand, reverting the original change would have been an easy way to restore the missing files. But doing so would make it appear as though the revert commit was introducing <em>brand new files with the same name as the ones which had been deleted<\/em>, rather than restoring the deleted files. The history before January 5 would have remained lost. A revert or a new commit which copies the files back remained an easy option, but something else was worth pursuing: restore the files with their history.<\/p>\n\n\n\n<figure class=\"wp-block-image alignleft size-full\"><a href=\"https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4.png\"><img loading=\"lazy\" decoding=\"async\" width=\"480\" height=\"849\" data-attachment-id=\"122538\" data-permalink=\"https:\/\/make.wordpress.org\/core\/2026\/06\/17\/recap-restoring-removed-version-history\/restore-branch-drawio-4\/#main\" data-orig-file=\"https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4.png\" data-orig-size=\"480,849\" data-comments-opened=\"1\" data-image-meta='{\"aperture\":\"0\",\"credit\":\"\",\"camera\":\"\",\"caption\":\"\",\"created_timestamp\":\"0\",\"copyright\":\"\",\"focal_length\":\"0\",\"iso\":\"0\",\"shutter_speed\":\"0\",\"title\":\"\",\"orientation\":\"0\",\"alt\":\"\"}' data-image-title=\"restore-branch.drawio-4\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4.png\" src=\"https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4.png\" alt=\"\" class=\"wp-image-122538\" srcset=\"https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4.png 480w, https:\/\/make.wordpress.org\/core\/files\/2026\/04\/restore-branch.drawio-4-170x300.png 170w\" sizes=\"auto, (max-width: 480px) 100vw, 480px\"><\/a><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The chosen resolution was to create a <span tabindex='0' class='glossary-item-container'>branch<span class='glossary-item-hidden-content'><span class='glossary-item-header'>branch<\/span> <span class='glossary-item-description'>A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a \"branch\", such as \"the 4.0 branch\".<\/span><\/span><\/span> of the code from the revision just before <a href=\"https:\/\/core.trac.wordpress.org\/changeset\/61438\">[61438]<\/a>, restore all of the files which were removed, and then perform a <em>merge<\/em> of the branch back into <code>trunk<\/code> to reconnect the version history. Until this point, creating branches was normal in the WordPress codebase for each release, but none had been reintegrated into <code>trunk<\/code> through a merge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The merge commit provided an opportunity to restore the file contents <em>and<\/em> connect them to their history. While the original plan was to create a branch with a single commit (the merge commit itself) <a href=\"https:\/\/profiles.wordpress.org\/desrosj\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>desrosj<\/a> had the suggestion that it would be valuable if the intervening history of changes could also be represented. In other words, to create the restore branch as an effective revert of <em>the decision<\/em> to remove all these files, not just the file objects themselves.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The result is that the restore branch contains a sequence of commits, where each is associated with a Gutenberg-sync commit in the upstream <code>trunk<\/code> branch. These commits modify the deleted files and introduce new files that <em>would have been<\/em> added had it not been for the <code>.gitignore<\/code> and <code>svn:ignore<\/code> changes. This is tantamount to checking out <code>trunk<\/code> at each Gutenberg sync commit, reverting the <code>.gitignore<\/code> changes, running <code>npm run build:dev<\/code>, and then adding the no-longer-ignored files (but the details are more complicated than this).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">After the final merge, it\u2019s now possible to examine one of the affected files and immediately know at which Gutenberg sync commit it changed and how. Supposing someone discovered that an issue appeared within the first quarter of 2026, this additional granularity might save the need to scan through hundreds of commits when debugging.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What was the process for the resolution?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The original change itself serves as a cautionary guide on how far-reaching the effects can be for fundamental changes to WordPress\u2019 development infrastructure. Because no restoration-merge had ever occurred, it was worth performing full diligence to prevent similar blowback while trying to fix the repository.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The approach was discussed early on and remained open for a long time to allow for rarer implications to surface \u2014 many did. The topic was brought up in <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64393\">Trac<\/a>, in the <a href=\"https:\/\/wordpress.slack.com\/archives\/C02RQBWTW\">#core<\/a> channel in <span tabindex='0' class='glossary-item-container'>Slack<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Slack<\/span> <span class='glossary-item-description'>Slack is a Collaborative Group Chat Platform <a href=\"https:\/\/slack.com\/\">https:\/\/slack.com\/<\/a>. The WordPress community has its own Slack Channel at <a href=\"https:\/\/make.wordpress.org\/chat\/\">https:\/\/make.wordpress.org\/chat\/<\/a><\/span><\/span><\/span>, and during <a href=\"https:\/\/wordpress.slack.com\/archives\/C02RQBWTW\/p1771429921631709\">weekly Developer Chats in #core<\/a>. The solution was brought to the attention of the systems team for their input, and as much as was possible, the restore was simulated at every stage to catch any failures which could be reasonably anticipated \u2013 many were.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>git<\/code> is a more powerful companion in situations like this than <code>svn<\/code> is, but ultimately all of WordPress\u2019 code must begin its life in <code>svn<\/code>. Therefore, a script was created to prototype a resolution in <code>git<\/code> to produce the desired outcome in a way that could be tested in local checkouts as well as run the test suite. The goalpost for this test branch was that, if done correctly, in the merge with <code>trunk<\/code> inside of its PR, there would be no follow-up commits from the bot that runs the build command (because no files would be changed through the build). The simulation script made it easy to adjust strategies and add missing steps once certain problems surfaced. One such problem was that some files didn\u2019t make it at the right time into one of the <code>grunt<\/code> lists when it should have; this could have involved a lot of manual work, but it didn\u2019t because of the script. The script still involved a lot of effort, but as many times as it ran, rebuilding the branch within a few minutes, it was clear that it was paying off.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Once the <code>git<\/code> branch was ready it was time to ensure that the steps in <code>svn<\/code> would actually produce that desired outcome once synchronized. For this, <a href=\"https:\/\/profiles.wordpress.org\/abbe\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>abbe<\/a> provided a test copy of the <code>develop.wordpress.org<\/code> Subversion repo that could be used to verify the flow. A second script stepped through each commit from the <code>git<\/code> branch and created mirrored commits on the <code>svn<\/code> side, then performed a merge into the test repo\u2019s <code>trunk<\/code> branch. The goalpost for this side was that the end result matched identically to the final  exploratory <code>git<\/code> branch. In the end, it took fifteen full iterations of the simulated branch creation to get the expected result. Imagine finding out all of the little nuances only <em>after<\/em> <span tabindex='0' class='glossary-item-container'>deploying<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Deploy<\/span> <span class='glossary-item-description'>Launching code from a local development environment to the production web server, so that it's available to visitors.<\/span><\/span><\/span> to production!<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With all of the details then ready, it was go-time and time to <span tabindex='0' class='glossary-item-container'>deploy<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Deploy<\/span> <span class='glossary-item-description'>Launching code from a local development environment to the production web server, so that it's available to visitors.<\/span><\/span><\/span> for real. Sadly, not all aspects of the flow were testable beforehand, and problems did arise which stalled the restoration. The \u201cbuild\u201d server<sup data-fn=\"8a03d9f0-98c6-4f69-b5d7-70b616a62464\" class=\"fn\"><a href=\"#8a03d9f0-98c6-4f69-b5d7-70b616a62464\" id=\"8a03d9f0-98c6-4f69-b5d7-70b616a62464-link\">2<\/a><\/sup> got stuck while processing commits due to a fatal Grunt error and <a href=\"https:\/\/profiles.wordpress.org\/aidvu\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>aidvu<\/a> had to step in and manually clear up the issues on that server. However, while delayed, all it took to reach the successful end was running the script once more. Thankfully, after preparing each commit and before pushing them, a pause step was built-in for manual review before <em>committing<\/em> to the commit, and this allowed coordination with systems (it\u2019s ideal to build natural throttles in to automation to avoid <em>billions of errors per second<\/em>).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is important to understand about this merge?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When working with merged branches, <code>git<\/code> automatically represents commits from all of the branches in history, but <code>svn<\/code> doesn\u2019t. This means that <code>git<\/code>-based workflows should be working without any trouble. But for those working in <code>svn<\/code>, a basic <code>svn log<\/code> will not show the corresponding sync-commits from the branch. One has to run <code>svn -g log<\/code> to see them. Any <code>svn<\/code>-based tooling will therefore hide the commits by default.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">There is one solvable nuance that was cut from scope for this resolution: commit authors and timestamps. While it was demonstrated to be technically possible to match the sync commits with their associated commits in the upstream <code>trunk<\/code> branch, this would have required rewriting metadata in <code>svn<\/code> <em>after<\/em> making the commits, and there was no certainty that this wouldn\u2019t interrupt the <code>git-svn<\/code> sync. Therefore, while each sync-commit matches another commit from January 5 through March 26, each of the restore-branch sync-commits appears in a bunch on March 26. This is a minor issue; regrettable but acceptable given the sensitivity of the work done to bring the repository back into a proper state.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What still remains to be done?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A few issues arose during the restoration, some of which highlighted pre-existing problems.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The <code>git<\/code> and subversion \u201cignores\u201d lists are incompatible and out of sync. These need to be harmonized and it would be ideal to have an automated process flag discrepancies before they are committed (<a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64971\" data-type=\"link\" data-id=\"file:\/\/\/var\/folders\/hy\/6y23234x12l733mnzg7ntn080000gn\/T\/zs-challenge-remote-image-e8b179c837cca903-viewer.html\">#64971<\/a>).<\/li>\n\n\n\n<li>A number of files have been deleted from the <code>git<\/code> repository over time which were never removed from the subversion side. This leaves stale files in <code>svn<\/code> and on the build server. These need to be identified, removed, and added to the <code>$_old_files<\/code> array in <code>wp-admin\/includes\/update-core.php<\/code> (see <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/65418\">#65418<\/a>). Automated detection would be helpful here as well (see <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64878\">#64878<\/a>).<\/li>\n\n\n\n<li>The continued discrepancy between <span tabindex='0' class='glossary-item-container'>WordPress Coding Standards<span class='glossary-item-hidden-content'><span class='glossary-item-header'>WordPress Coding Standards<\/span> <span class='glossary-item-description'>The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress <a href=\"https:\/\/developer.wordpress.org\/coding-standards\/\">Coding Standards Handbook<\/a>.\rMay also refer to <a href=\"https:\/\/github.com\/WordPress\/WordPress-Coding-Standards\/\">The collection of PHP_CodeSniffer rules<\/a> (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards.<\/span><\/span><\/span> preferences between the Gutenberg and Core repositories remains an obstacle to harmony between the projects. Rulesets should be normalized or removed from the repositories so that accepted changes don\u2019t suddenly reject PRs when synchronizing. This issue also recently came up when restoring the WordPress documentation, as PHP code which was accepted in Gutenberg broke the docs\u2019 generation process once built in Core. This was due to the use of syntax forms which were already known to break tooling and integrations.<\/li>\n\n\n\n<li>Functions and <span tabindex='0' class='glossary-item-container'>hooks<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Hooks<\/span> <span class='glossary-item-description'>In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.<\/span><\/span><\/span> maintained upstream in the <code>gutenberg<\/code> repository that are built from the new template files in the <code>wp-build<\/code> package lack proper PHP <span tabindex='0' class='glossary-item-container'>Docblock<span class='glossary-item-hidden-content'><span class='glossary-item-header'>docblock<\/span> <span class='glossary-item-description'>(phpdoc, xref, inline docs)<\/span><\/span><\/span> comments. Mainly, action and <span tabindex='0' class='glossary-item-container'>filter<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Filter<\/span> <span class='glossary-item-description'>Filters are one of the two types of Hooks <a href=\"https:\/\/codex.wordpress.org\/Plugin_API\/Hooks\">https:\/\/codex.wordpress.org\/Plugin_API\/Hooks<\/a>. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.<\/span><\/span><\/span> hooks had incorrectly formatted Docblocks (fixed in <a href=\"https:\/\/github.com\/WordPress\/gutenberg\/pull\/78826\">Gutenberg-78826<\/a>), and missing <code>@since<\/code> tags (see <a href=\"https:\/\/github.com\/WordPress\/gutenberg\/issues\/76727\">Gutenberg-76727<\/a>).<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">A few other unrelated issues persist as a result of the build change.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The workflow for developing simultaneously with the Core and Gutenberg repositories needs to be restored, as the traditional approach of mounting the Gutenberg plugin into the <code>wp-content\/plugins\/<\/code> directory was severed in the change.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Thanks you!<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A heartfelt \u201cthank you\u201d goes out to everyone who helped with overhauling the build script to reduce friction between the two code bases, and\/or this effort to restore file history:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/profiles.wordpress.org\/4thhubbard\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>4thhubbard<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/762e5e74\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>762e5e74<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/adamsilverstein\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>adamsilverstein<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/aidvu\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>aidvu<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/amykamala\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>amykamala<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/bernhard-reiter\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>bernhard-reiter<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/dd32\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>dd32<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/desrosj\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>desrosj<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/dmsnell\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>dmsnell<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/ellatrix\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>ellatrix<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/gaisma22\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>gaisma22<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/isabel_brison\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>isabel_brison<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/johnbillion\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>johnbillion<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/jonsurrell\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>jonsurrell<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/jorbin\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>jorbin<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/jorgefilipecosta\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>jorgefilipecosta<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/jsnajdr\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>jsnajdr<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/jtquip88\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>jtquip88<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/mamaduka\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>mamaduka<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/manhar\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>manhar<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/manzoorwanijk\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>manzoorwanijk<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/mcsf\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>mcsf<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/mywp459\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>mywp459<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/ntsekouras\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>ntsekouras<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/peterwilsoncc\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>peterwilsoncc<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/sabernhardt\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>sabernhardt<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/sirlouen\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>SirLouen<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/swissspidy\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>swissspidy<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/tobiasbg\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>tobiasbg<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/tyxla\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>tyxla<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/westonruter\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>westonruter<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/wildworks\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>wildworks<\/a>, and <a href=\"https:\/\/profiles.wordpress.org\/youknowriad\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>youknowriad<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Timeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>January 5 \u2014 The change was committed.<\/li>\n\n\n\n<li>January 6 \u2014 The first set of problems was reported.<\/li>\n\n\n\n<li>February 23 \u2014 An initial <code>git<\/code> branch was proposed which restored the files in their final state.<\/li>\n\n\n\n<li>March 6 \u2014 The restore branch was created in Subversion, and successfully synchronized to <code>git<\/code>.<\/li>\n\n\n\n<li>March 18 \u2014 An expanded <code>git<\/code> branch contained a commit for every associated Gutenberg sync commit in Core.<\/li>\n\n\n\n<li>March 24 \u2014 Systems provided a test <code>svn<\/code> repository from a backup of <code>develop.svn.wordpress.org<\/code> where a final merge could be tested before being applied to the production repository.<\/li>\n\n\n\n<li>March 26 \u2014 The branch was merged into Core, restoring the files and their change history.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\">\n\n\n\n<p class=\"has-text-align-right wp-block-paragraph\"><em>Props to <a href=\"https:\/\/profiles.wordpress.org\/amykamala\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>amykamala<\/a> and <a href=\"https:\/\/profiles.wordpress.org\/desrosj\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>desrosj<\/a> who reviewed this post before publishing.<\/em><\/p>\n\n\n<ol class=\"wp-block-footnotes\"><li id=\"8a03d9f0-98c6-4f69-b5d7-70b616a62464\">The <span tabindex='0' class='glossary-item-container'>wordpress.org<span class='glossary-item-hidden-content'><span class='glossary-item-header'>WordPress.org<\/span> <span class='glossary-item-description'>The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization.  <a href=\"https:\/\/wordpress.org\/\">https:\/\/wordpress.org\/<\/a><\/span><\/span><\/span> build server checks out each commit to the <code>wordpress-develop<\/code> SVN repository, runs <code>npm install<\/code>, <code>npm run build<\/code>, and then commits any changes to the <code>build<\/code> directory to the <a href=\"https:\/\/core.svn.wordpress.org\/\">core.svn.wordpress.org repository<\/a>. All release packages are created from this repository. <a href=\"#8a03d9f0-98c6-4f69-b5d7-70b616a62464-link\" aria-label=\"Jump to footnote reference 1\">\u21a9\ufe0e<\/a><\/li><\/ol><p class=\"o2-appended-tags\"><a href=\"https:\/\/make.wordpress.org\/core\/tag\/build-test-tools\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>build-test-tools<\/a>, <a href=\"https:\/\/make.wordpress.org\/core\/tag\/git\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>git<\/a>, <a href=\"https:\/\/make.wordpress.org\/core\/tag\/post-mortem\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>post-mortem<\/a>, <a href=\"https:\/\/make.wordpress.org\/core\/tag\/svn\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>svn<\/a><\/p><nav class='o2-post-footer-actions'><ul class='o2-post-footer-action-row'><li class='o2-post-footer-action'><a href=\"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2026%2F06%2F17%2Frecap-restoring-removed-version-history%2F%23respond&#038;locale=en_US\" title=\"Login to Reply\"  class=\"genericon  genericon-reply\"  data-action=\"login-to-reply\"  data-actionstate=\"default\" >Login to Reply<\/a><\/li><\/ul><div class='o2-post-footer-action-likes'><\/div><ul class='o2-post-footer-action-row'><\/ul><\/nav>","protected":false},"excerpt":{"rendered":"<p>Since the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user [&hellip;]<\/p>\n","protected":false},"author":13597958,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"[{\"id\":\"8a03d9f0-98c6-4f69-b5d7-70b616a62464\",\"content\":\"The wordpress.org build server checks out each commit to the <code>wordpress-develop<\\\/code> SVN repository, runs <code>npm install<\\\/code>, <code>npm run build<\\\/code>, and then commits any changes to the <code>build<\\\/code> directory to the <a href=\\\"https:\\\/\\\/core.svn.wordpress.org\\\/\\\">core.svn.wordpress.org repository<\\\/a>. All release packages are created from this repository.\"}]","jetpack_post_was_ever_published":false},"categories":[1175],"tags":[3424,124,1480,225],"class_list":["post-122418","post","type-post","status-publish","format-standard","hentry","category-general","tag-build-test-tools","tag-git","tag-post-mortem","tag-svn","mentions-4thhubbard","mentions-762e5e74","mentions-abbe","mentions-adamsilverstein","mentions-aidvu","mentions-amykamala","mentions-bernhard-reiter","mentions-dd32","mentions-desrosj","mentions-dmsnell","mentions-ellatrix","mentions-gaisma22","mentions-isabel_brison","mentions-johnbillion","mentions-jonsurrell","mentions-jorbin","mentions-jorgefilipecosta","mentions-jsnajdr","mentions-jtquip88","mentions-mamaduka","mentions-manhar","mentions-manzoorwanijk","mentions-mcsf","mentions-mywp459","mentions-ntsekouras","mentions-peterwilsoncc","mentions-sabernhardt","mentions-sirlouen","mentions-swissspidy","mentions-tobiasbg","mentions-tyxla","mentions-westonruter","mentions-wildworks","mentions-youknowriad","author-dmsnell"],"revision_note":"","jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2AvED-vQu","_links":{"self":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/122418","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/users\/13597958"}],"replies":[{"embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/comments?post=122418"}],"version-history":[{"count":93,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/122418\/revisions"}],"predecessor-version":[{"id":123987,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/122418\/revisions\/123987"}],"wp:attachment":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/media?parent=122418"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/categories?post=122418"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/tags?post=122418"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}