![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#65418 closed defect (bug) (fixed)
Previously copied files since deleted from the Gutenberg asset are persisting unexpectedly
| Reported by: | desrosj | Owned by: | desrosj |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.0.1 |
| Component: | Build/Test Tools | Version: | |
| Severity: | normal | Keywords: | has-patch fixed-major dev-reviewed commit |
| Cc: | Focuses: |
Description (last modified by )
When a file was removed from the Gutenberg repository upstream, it currently persists in src/wp-includes/ indefinitely unless someone knows to manually delete it. While the build process copies new files in, it never performs a proper clean.
In the past this has primarily surfaced as built CSS files remaining in src/wp-includes/blocks/* directories, which would cause the grunt verify:old-file task to fail.
After the changes associated with #64393, files that are removed from the built asset pulled in from the GitHub Container Registry are not deleted as they should be. This results in files persisting in WordPress when they should instead be removed.
Change History (16)
This ticket was mentioned in PR #12105 on WordPress/wordpress-develop by @desrosj.
6 weeks ago
#1
#2
@
6 weeks ago
Before applying the patch, files that had been removed from Gutenberg remained in the WordPress checkout after running the build process.
After applying the patch, the cleanup step correctly removed the stale files, including the Icon Library assets, before the new files were copied over.
The behavior now matches expectations and prevents obsolete Gutenberg assets from persisting in the repository.
#3
@
6 weeks ago
Thanks @tusharaddweb!
Can you please provide a more detailed breakdown of how you tested the changes? With the current state of the PR, I am seeing that the related directories in src are not recreated as expected. So I'd like to better understand what you are seeing.
This ticket was mentioned in PR #12206 on WordPress/wordpress-develop by @desrosj.
5 weeks ago
#4
When a file was removed from the Gutenberg repository upstream, it currently persists in src/wp-includes/ indefinitely unless someone knows to manually delete it. While the build process copies new files in, it never performs a proper clean.
This PR makes a few changes to address this and fix some loosely related pre-existing bugs along the way
First, all Gutenberg-sourced files are now built into src. Because files were previously built into the WORKING_DIRECTORY, when someone ran a combination of build:dev and build after pulling recent changes that modified file names or added/removed files, this sometimes resulted in built files being out of sync, or stale version controlled files in src despite them appearing "correct" in build.
Second, the clean:gutenberg is now the first task run as part of build:gutenberg. It has also been updated to clean all versioned and unversioned files managed by the Gutenberg-related build scripts. However, only versioned files will only be cleaned if clean:gutenberg is called directly. If grunt clean is called, then only _unversioned_ files are cleaned. This is to avoid a dirty state after running grunt clean where versioned files have been deleted and not regenerated.
Lastly, the jsFiles has been adjusted so that gutenbergVersionedFiles, gutenbergUnversionedFiles and webpackFiles become reponsible for the files generated in the respective tasks.
Trac ticket: Core-65418.
AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.7 & 4.8
Used for: Analyzing and documenting the various tasks and scripts and the outcomes of different build paths before creating a first draft of this PR that was adjusted and reviewed by me.
@desrosj commented on PR #12105:
5 weeks ago
#5
Closing in favor of #12206.
#7
@
4 weeks ago
- Keywords fixed-major added
This was fixed in [62525].
Marking for backport consideration.
@desrosj commented on PR #12206:
4 weeks ago
#8
Resolved in r62525.
#9
@
4 weeks ago
One side effect of [62525] is that the /*! This file is auto-generated */ banner is now added at the top of the .min.js files sourced from the built zip file because those files are now present before usebanner:files is run by way of build:css.
I don't think this is a huge deal, but it's worth flagging for discussion in case there's something I'm missing.
#10
@
4 weeks ago
I am not overly concerned with a double banner, but I'm also not seeing it in any of the files I checked in https://github.com/WordPress/wordpress/. Can you point to an example?
#12
@
3 weeks ago
- Keywords dev-reviewed added
Ah, I thought it was adding a double banner and that was what I was looking forward. I have no concerns about this. Approved for backport to 7.0 branch.
This fixes two issues with the Gutenberg-related build tasks:
gutenbergFileslist.clean:gutenbergtask is not run before building, which results in removed files potentially remaining unexpectedly.Trac ticket: Core-65418.
## Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.7
Used for: Analyzing the code and identifying the root cause for the files persisting.