Repository navigation
fix(core): download WordPress core without truncated file names - #241
Merged
mrrobot47 merged 4 commits intoSep 29, 2026
Merged
Conversation
`wp core download` with WP-CLI <= 2.12 extracts the .tar.gz with PharData, which truncates paths over 100 bytes in the PAX headers of WordPress >= 6.7.2 en_US packages (wp-cli/wp-cli#6320). New 7.x sites were missing wp-includes/php-ai-client classes. Use site-command's get_wp_core_download_command(), which extracts with tar/unzip and checks the result with `wp core verify-checksums`. Also fix the retry loop: its EE::error() was unreachable, so a failed download went unnoticed and site creation carried on. Failures now throw, which runs the usual clean-up, and report WP-CLI's error. Errors that retrying can't fix (unknown version or locale, checksum failures) aren't retried. --version and --skip-content are no longer concatenated into the shell command unescaped. Requires the site-command release that adds get_wp_core_download_command().
… sites Sites created with the old `wp core download` on WordPress 7.x have 25 missing and 21 truncated files under wp-includes/php-ai-client/. A later core update restores the missing ones but leaves the truncated leftovers. For each enabled WordPress site with that directory, run `wp core verify-checksums` in the php container and match its warnings under wp-includes/php-ai-client/ (the exit code is 0 in the healed state). Restore only that directory from the md5-checked package of the site's version and locale, delete the leftovers (90-character, non-.php names flagged by verify-checksums) and verify again. No database, WordPress is never loaded, and it can be re-run. Sites that are stopped, can't be checked or fail to repair get a warning with the manual check; the migration itself never fails.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The migration can be permanently skipped when its dependency is unavailable and can report success after an unsuccessful final verification.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Updates WordPress core downloads and repairs installations affected by truncated archive paths.
Changes:
- Uses the shared verified download/extraction helper with retry handling.
- Adds an idempotent migration to repair affected WordPress installations.
| File | Description |
|---|---|
src/WordPress.php |
Replaces direct WP-CLI downloads with the shared helper. |
migrations/container/20260924160000_site-type-wp_repair_truncated_core_files.php |
Detects and repairs truncated core files. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…download helper - When WordPress.org's checksums can't be fetched, the download still succeeds, but its "Could not verify WordPress core checksums" warning now reaches the user instead of only the debug log. - A site-command without `get_wp_core_download_command()` now fails the create with a clear message and the usual clean-up, instead of an `\Error` that `create_site()` doesn't catch. - The failure reason no longer repeats WP-CLI's "Error: " prefix. - The retry comment now says why force is needed on every path.
… verified repairs - The package is extracted into a temp dir and only then copied into wp-includes/php-ai-client/. A corrupt package from WP-CLI's cache, which isn't md5-checked again, used to leave half-written files in a working site; now a fresh copy is fetched once instead. - Only extra files with the truncated-name signature count as leftovers, so other files in php-ai-client/ no longer cause a false "Could not repair" warning. - The final check fails on checksum mismatches under php-ai-client/ and reports "unverified" when the checksums can't be fetched, instead of claiming the repair was verified. - Disabled sites and a site-command without the helper now get a warning with the manual check command instead of being skipped silently, since the migration is recorded either way. - "unverified" reasons show WP-CLI's error line, and the docblock says which packages and files are covered.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on EasyEngine/site-command#504, which is merged: this PR calls the
get_wp_core_download_command()helper added there, so both need to be released and pinned together.Problem
WordPress 7.x
.tar.gzpackages store paths longer than 100 bytes in PAX headers. WP-CLI 2.12 and older extracts them with PHP'sPharData, which ignores those headers and truncates the names (wp-cli/wp-cli#6320, php/php-src#19311). On every new en_US WordPress 7.x site, 25 files underwp-includes/php-ai-client/get truncated names and some are lost, so WordPress fatals as soon as the AI client is used, andwp core verify-checksumsfails. Localized packages aren't affected.Sites that were already created this way stay broken. A later core update restores the missing files but leaves the 21 truncated leftovers behind.
Fix
ee site create --type=wpnow downloads core through site-command's shared download helper:wp core download --no-extract, extraction withtarorunzip, then awp core verify-checksumsgate.EE::error()was unreachable, so a failed download went unnoticed and site creation carried on. Failures now throw, which runs the usual clean-up, and report WP-CLI's error without repeating its "Error: " prefix. Errors that retrying can't fix (unknown version or locale, checksum failures) aren't retried.\Error.--versionand--skip-contentare no longer concatenated into the shell command unescaped.wp-includes/php-ai-client/, it runswp core verify-checksumsin the php container, extracts that directory from the site's version and locale package into a temp dir and only then copies it in, deletes the truncated leftovers and verifies again. A corrupt package from WP-CLI's cache is replaced by a fresh md5-checked download, so it can't leave half-written files.php-ai-client/are left alone. A site is reported as repaired only when the final check passes; when the checksums can't be fetched, the migration says the repair is unverified.php-ai-clientfiles. The 14 truncated default-theme files that en_US 6.7.2+ sites keep underwp-contentaren't covered byverify-checksums, so they aren't repaired.Testing
--skip-content, 6.9) on PHP 7.4 to 8.5 passwp core verify-checksumswith all 146php-ai-clientfiles in place.--versionor--localefails after one attempt with WP-CLI's error and leaves nothing behind. So does a create with a site-command that lacks the helper.