Make `composer test-wp-env` and WP-integration asset tests work from a git worktree

[enricobattocchi]

Context

Running composer test-wp-env from a git worktree whose directory is not literally named wordpress-seo currently fails. Worktrees are the natural way to run an isolated build / test cycle on a parallel branch (and they're explicitly recommended for AI coding agents per AGENTS.md's "delegate long-running commands"), so this friction shows up regularly.

Reproduced from a worktree of trunk whose host directory was renamed (in this case to match the branch name) while testing #23214.

Two concrete blockers

1. The wrapper script hardcodes the in-container plugin path

config/scripts/run-wp-env-tests.sh:

PLUGIN_PATH="/var/www/html/wp-content/plugins/wordpress-seo"
…
npx wp-env run cli --env-cwd="$PLUGIN_PATH" -- env $ENV_PREFIX php vendor/phpunit/phpunit/phpunit -c phpunit-wp.xml.dist …

wp-env mounts the plugin at /var/www/html/wp-content/plugins/<host-dirname>. From a worktree whose directory name differs, the hardcoded …/plugins/wordpress-seo doesn't exist in the container, so the run aborts with:

OCI runtime exec failed: chdir to cwd ("/var/www/html/wp-content/plugins/wordpress-seo") set in config.json failed: no such file or directory: unknown
✖ Command failed with exit code 126

Suggested fix: derive the path from the actual host directory name. Something like:

PLUGIN_DIR="$(basename "$PROJECT_DIR")"
PLUGIN_PATH="/var/www/html/wp-content/plugins/$PLUGIN_DIR"

That keeps the existing canonical-checkout case working while letting any worktree run too.

2. A handful of WP-integration tests assert literal wordpress-seo in asset URLs

After working around (1), three tests fail purely on the directory string:

• Yoast\WP\SEO\Tests\WP\Admin\Asset_Manager_Test::test_register_script
• Yoast\WP\SEO\Tests\WP\Admin\Asset_Manager_Test::test_register_style
• Yoast\WP\SEO\Tests\WP\Admin\Asset_SEO_Location_Test::test_get_url

Example diff (the path component on the right is whatever the worktree directory happens to be named):

- 'http://example.org/wp-content/plugins/wordpress-seo/js/dist/src.js'
+ 'http://example.org/wp-content/plugins/<worktree-dirname>/js/dist/src.js'

Suggested fix: build the expected URL from the plugin's actual location at runtime — e.g. plugin_dir_url( WPSEO_FILE ) / plugin_basename( WPSEO_FILE ) — rather than hardcoding the directory name in the assertion. That makes the tests worktree-name-agnostic without weakening their coverage.

(There were two more failures in Post_Site_Information_Test::test_legacy_site_information / ::test_site_information — same root cause likely. Worth a sweep.)

Bonus: vendor/ symlinks don't survive the container boundary

Less critical, more documentation: a worktree without its own vendor/ is a common starting state. Symlinking vendor to the main checkout's vendor works for host-side PHPUnit / phpcs but breaks inside wp-env because the symlink target is an absolute host path the container can't resolve. So composer test-wp-env from a worktree currently requires a real composer install in that worktree (which also re-runs compile-di via the post-autoload-dump hook). Worth a one-line mention in docs/workflows/ next to whatever wp-env documentation exists.

Acceptance

• composer test-wp-env runs end-to-end from a worktree at any directory name.
• The 5 currently-failing WP\Admin\Asset_* and Post_Site_Information tests pass under any worktree directory name.
• A short note about vendor/ per worktree appears wherever the wp-env workflow is documented.