Installation Tests: single-site installs of 5.9 and 6.0 fatal on a truncated Twenty Twenty-Two pattern file

[lancewillett]

Since [63517] added a post-install smoke check to the Installation Tests workflow, single-site installs of WordPress 5.9 and 6.0 fatal. Multisite skips the smoke check, so it passes.

Example, WP 5.9.20: ​https://github.com/WordPress/wordpress-develop/actions/runs/40768551377

require(): Failed opening required '.../wp-content/themes/twentytwentytwo/inc/patterns/header-text-only-with-tagline-black-background.php'

The file is in the release packages. The workflow downloads with wp core download, which fetches the tarball. WP-CLI 2.12.0, the version setup-php installs, extracts tarballs with PharData first (​Extractor.php). PharData cuts this file's 107-character path at 100 characters, so it lands as …black-backgro with no .php.

Before [63517], the install tests stopped at wp core install and never loaded the theme, so this was never seen.

WP-CLI's main branch now runs tar xz first and falls back to PharData only on error, but no release CI uses includes that yet.

Possible fixes:

1. Download the tarball and extract it with the system tar in install-testing.yml.
2. Move CI to a WP-CLI release that includes the tar xz-first change, once one ships.

Follow-up to #66036.

The Installation Tests workflow now downloads release tarballs with curl and extracts them with the system tar.

WP-CLI 2.12.0 extracts tarballs with PharData, which cuts paths at 100 characters. On WordPress 5.9 and 6.0, twentytwentytwo/inc/patterns/header-text-only-with-tagline-black-background.php loses its .php extension, and the post-install smoke check fails with a fatal error. The system tar keeps the full path.

nightly and trunk still use wp core download. Nightly builds are only available as a zip, and the zip extraction does not cut paths.

Testing

Run the Installation Tests workflow manually with wp-version set to 5.9, 6.0, latest, and nightly. All single-site jobs pass the smoke check.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Investigation, implementation, and review. I reviewed the final change.

[johnbillion]

This should be fixed in the next version of WP-CLI ​https://github.com/wp-cli/wp-cli/issues/6320

[lancewillett]

I'll land this; then @adrianmoldovanwp could you investigate updating to the latest version of wp cli?

[lancewillett]

In 65004:

Build/Test Tools: Preserve filenames in installation test downloads.

Download release archives with curl and extract them with the system tar to avoid truncated filenames from PharData. This fixes the Twenty Twenty-Two pattern loading failure in WordPress 5.9 and 6.0 installation smoke checks.

Keep wp core download for nightly and trunk, which use ZIP archives.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/15152

Props adrianmoldovanwp.
Fixes #66403.

@adimoldovan Could you please follow up in a new PR/Trac ticket for how we might upgrade to latest version of WP CLI to avoid this patch? See https://core.trac.wordpress.org/ticket/66403#comment:3

[adrianmoldovanwp]

The curl + tar workaround from PR 15152 is now in trunk. The WP-CLI fix is expected to land in version 3.0. But that will bring another issue - it needs PHP 7.2.24 or later. Installation Tests still run WP 4.7–6.5 on PHP 5.4–7.1, so those jobs must stay on WP-CLI 2.x.

In any case, we should pin WP-CLI 2.12.0 for PHP 5.6, 7.0 and 7.1 before WP-CLI 3.0 ships. Otherwise those jobs will fail. PHP 5.4 and 5.5 already have 2.4.0 pinned.

Options to remove the curl workaround:

1. Download the zip with WP-CLI: wp core download "https://wordpress.org/wordpress-${WP_VERSION}.zip". WP-CLI extracts zip files with ZipArchive, which keeps long paths. It works with WP-CLI 2.4.0, 2.12.0 and 3.0.0-alpha, and it checks the MD5 hash. We can do it now for all versions.
2. Wait for WP-CLI 3.0 and go back to wp core download --version=X. This fixes only the jobs on PHP 7.2+. Jobs on older PHP still need option 1.
3. Ask WP-CLI to backport the fix to a 2.x release. Then all jobs can use wp core download --version=X. The jobs pinned to 2.4.0 keep the bug, but it does not show: the tarballs for WP 4.7–5.1 have no path longer than 100 characters.

I would go with option 1 together with the pin, in one change. I would not limit the zip download to jobs on WP-CLI 2.x: WP-CLI 3.0 downloads the same zip file, so a condition adds code but does not change the result.

[lancewillett]

Thanks, @adrianmoldovanwp. I agree with option 1 and the version pins in one follow-up PR.

Please preserve the latest, nightly, and trunk handling, and validate the oldest PHP jobs alongside WordPress 5.9 and 6.0. That removes the workaround without adding a WP-CLI-version branch or waiting for 3.0.

The Installation Tests workflow now downloads release zips with wp core download, and pins WP-CLI 2.12.0 on PHP 5.6, 7.0 and 7.1.

This removes the curl + tar workaround from [65004]. WP-CLI 2.x extracts tarballs with PharData, which cuts paths at 100 characters. It extracts zips with ZipArchive, which keeps the full path. wp core download also checks the MD5 hash of the zip.

WP-CLI 3.0 will need PHP 7.2.24 or later. On PHP 5.6, 7.0 and 7.1 it exits with "WP-CLI requires PHP 7.2.24 or newer". The pin keeps these jobs on 2.12.0. PHP 5.4 and 5.5 stay on 2.4.0.

latest, nightly and trunk work as before. nightly and trunk still use wp core download --version=nightly.

Testing

Run the Installation Tests workflow manually with wp-version set to 4.9, 5.9, 6.0, latest and nightly. All install jobs pass.

Results on my fork, with this change and the github.repository checks removed so the jobs run outside WordPress/wordpress-develop:

• WP 4.9 (PHP 5.4–7.2, WP-CLI 2.4.0 on PHP 5.4 and 5.5): ​24 of 24 install jobs pass
• WP 5.9: ​48 of 48 install jobs pass
• WP 6.0: ​48 of 48 install jobs pass
• latest: ​70 of 70 install jobs pass
• nightly: ​70 of 70 install jobs pass

The PHP 5.6 and 7.1 job logs show WP-CLI 2.12.0, Downloading from https://wordpress.org/wordpress-5.9.20.zip and md5 hash verified.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Investigation, implementation, and review. I reviewed the final change.