Repository navigation
Conversation
WP-CLI <= 2.12 extracts core .tar.gz packages with PharData, which ignores PAX long-name headers and truncates paths over 100 bytes (wp-cli/wp-cli#6320, php/php-src#19311). WordPress >= 6.7.2 en_US packages use PAX headers, so 7.x installs lose wp-includes/php-ai-client classes and fatal when the AI client is used. get_wp_core_download_command() lets WP-CLI resolve the version and locale and verify the md5 with `core download --no-extract`, extracts the package with tar (or unzip, falling back to ZipArchive) and gates on `core verify-checksums`: missing or modified files fail, an unreachable checksums API only warns. WP-CLI >= 3.0 saves a .zip (wp-cli/core-command#333), which is handled too. --skip-content and nightly keep WP-CLI's own extraction, as they already use the unaffected .zip path. Arguments are shell-escaped for the bash -c wrapper.
The restore ran `wp core download --force`, which truncates WordPress 7.x core files like site creation did. Use get_wp_core_download_command() instead. With force, wp-admin and wp-includes are replaced after a successful download, so a restore onto a newer or already corrupted core leaves no stale files behind.
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Verification failures can be incorrectly ignored, and non-force downloads can overwrite existing installations.
Review effort: Balanced
Findings: 1
Open (2)
What changed in this PR
Updates WordPress restores to avoid truncated core files by delegating extraction to native archive tools and verifying checksums.
Changes:
- Adds WordPress package download, extraction, and verification helpers.
- Uses the new helper during site restoration.
| File | Description |
|---|---|
src/helper/site-utils.php |
Adds safe WordPress core download and extraction utilities. |
src/helper/Site_Backup_Restore.php |
Integrates the helper into WordPress restoration. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…k fails Extract the package into the temp dir and only then replace wp-admin and wp-includes, so a failed extraction (a corrupt cached package, a full disk) no longer leaves a site without core. A package from WP-CLI's cache isn't md5-checked again, so a failed extraction fetches a fresh copy once. ee_wp_verify now fails unless core verifies, and only warns when the checksums can't be fetched from WordPress.org. Before, any other failure, such as "This does not seem to be a WordPress install", passed as a warning. Without force, refuse to extract over an existing install, as WP-CLI does.
iamimmanuelraj
added a commit
to iamimmanuelraj/action-deploy-wordpress
that referenced
this pull request
Oct 5, 2026
Any other verify-checksums failure (PHP/WP-CLI runtime errors etc.) now fails the deploy instead of continuing unverified. Matches the fetch-error handling in EasyEngine/site-command#504.
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.
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). The files underwp-includes/php-ai-client/end up with broken names, some are lost, and WordPress fatals as soon as the AI client is used.wp core verify-checksumsfails on such a tree.ee site restorerunswp core download --force, so a restored WordPress 7.x site gets this broken core.Fix
get_wp_core_download_command()and its shell helpers insite-utils.php. They let WP-CLI resolve the version and locale and check the md5 withwp core download --no-extract, extract the package withtar(orunzip, with aZipArchivefallback), and then runwp core verify-checksums. The download fails unless core verifies; it only warns when the checksums can't be fetched from WordPress.org..zipthat WP-CLI 3.0 saves is handled too.--skip-contentand nightly keep WP-CLI's own extraction, since those already use the unaffected.zippath.force,wp-adminandwp-includesare replaced only after a successful extraction, so restoring onto a newer or already broken core leaves no stale files. Withoutforce, the helper refuses to extract over an existing install, as WP-CLI does.force. An empty WordPress version in the backup metadata now means latest.Testing
wp core verify-checksumspassing and the site's content intact.Dependencies
A follow-up site-type-wp PR switches site creation to the same helper and repairs existing sites, so this PR needs to be merged and released first.