Fix incorrect home/siteurl when WP-CLI runs from root filesystem

[Copilot]

Fix "core install" URL when wp-cli is executed from root filesystem

Resolves the issue where wp core install defines incorrect home and siteurl values when WP-CLI is executed from the root of the filesystem.

Problem

When WP-CLI phar is located at the root of the filesystem (e.g., /wp) and WordPress is installed at a different path (e.g., /home/customer/website), the wp core install command sets incorrect home and siteurl values. Instead of using the URL provided via the --url parameter (e.g., https://website.domain.tld), it produces malformed URLs like https://website.domain.tldhome/customer/website.

Root Cause

WordPress's internal URL detection functions (like wp_guess_url()) use $_SERVER['PHP_SELF'] and $_SERVER['SCRIPT_NAME'] to determine the script path. When WP-CLI is executed from /wp, these variables contain /wp (the path to the WP-CLI phar) rather than the WordPress installation path, which causes incorrect URL construction during wp_install().

Solution

The fix sets $_SERVER['PHP_SELF'], $_SERVER['SCRIPT_NAME'], and $_SERVER['SCRIPT_FILENAME'] to match the URL path provided via the --url parameter. The fix is now applied at multiple levels:

1. In the public install() and multisite_install() methods before calling do_install()
2. In do_install() itself before loading WordPress files or calling WP_CLI::set_url()

This layered approach ensures the correct values are set as early as possible, before WordPress has a chance to cache or use incorrect values.

Changes

• Modified install() method to set proper $_SERVER variables before calling do_install()
• Modified multisite_install() method to set proper $_SERVER variables before calling do_install()
• Kept fix in do_install() method as well for defense in depth
• Added comprehensive comments explaining the fix
• Used pathinfo() for secure file extension detection
• Used Utils\trailingslashit() for safe path construction
• Added Behat test scenarios to verify correct URLs are set
• All code passes PHPCS checks

Testing

• Added test scenarios for URLs without paths (example.com) and with paths (example.com/subdir)
• Simplified test scenario to focus on basic functionality
• The fix applies to both wp core install and wp core multisite-install

Security

• Used pathinfo() instead of string matching for robust file extension detection
• Used Utils\trailingslashit() for safe path construction to prevent path traversal issues
• All security checks passed

Original prompt

---

This section details on the original issue you should resolve

<issue_title>"core install" defines an incorrect home and siteurl if wpcli is executed from the root of the filesystem</issue_title>
<issue_description>## Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

"core install" defines an incorrect home and siteurl if wpcli is executed from the root of the filesystem.

Describe how other contributors can replicate this bug

• Copy the wpcli phar package on / (for example: /wp)
• Call "/wp core install" with valid --path and --url (for exemple: --path="/home/customer/website" and --url= "https://website.domain.tld")
• The siteurl and home options are incorrect in the database (for example: https://website.domain.tldhome/customer/website instead of https://website.domain.tld)

Describe what you would expect as the correct outcome

Those values should be identical to the --url passed to the "core install" command and not depending on the path where the wpcli executable is located.

Let us know what environment you are running this on

wp-cli 2.12.0 on Debian 11 and PHP 8.4.

OS:	Linux 5.10.0-34-amd64 wp-cli/core-command#1 SMP Debian 5.10.234-1 (2025-02-24) x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php8.4
PHP version:	8.4.14
php.ini used:	/etc/php/8.4/cli/php.ini
MySQL binary:	/usr/bin/mariadb
MySQL version:	mariadb  Ver 15.1 Distrib 10.5.29-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	phar:///wp
WP-CLI packages dir:	/home/www/.wp-cli/packages/
WP-CLI cache dir:	/home/www/.wp-cli/cache
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.12.0

Provide additional context

I stumbled into this issue because i'm executing wpcli on a bubblewrap microcontainer where i was bind mounting the wpcli phar on the root of the virtual filesystem for convenience but the issue is not related to bubblewrap as it's happening even on the host OS.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes "core install" defines an incorrect home and siteurl if wpcli is executed from the root of the filesystem #297

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[codecov]

Codecov Report

❌ Patch coverage is 62.50000% with 15 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Core_Command.php	62.50%	15 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

Fixes malformed home/siteurl values during wp core install when WP-CLI is executed from the filesystem root by ensuring WordPress’s URL guessing logic sees server paths that reflect the --url value.

Changes:

• Override $_SERVER['PHP_SELF'] / $_SERVER['SCRIPT_NAME'] (and conditionally $_SERVER['SCRIPT_FILENAME']) during installation based on the parsed --url path.
• Normalize URL paths to an index.php-style script path for WordPress’s install-time URL detection.
• Add Behat coverage for installs with --url values with and without a path component.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Core_Command.php	Adjusts server superglobals during install so WP’s wp_guess_url() derives the correct base URL.
features/core-install.feature	Adds scenarios asserting home/siteurl values for URLs with and without a path.

---

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

[gemini-code-assist]

Code Review

The pull request effectively addresses the issue of incorrect home and siteurl values when WP-CLI is executed from the root filesystem. The solution correctly manipulates $_SERVER variables to ensure WordPress's URL detection functions behave as expected. The addition of comprehensive Behat tests is a significant improvement, verifying the fix across various URL structures. The use of pathinfo() and Utils\parse_url() contributes to the robustness and security of the solution.

[gemini-code-assist]

The logic for setting $_SERVER variables based on the provided URL is duplicated across install(), multisite_install(), and do_install(). While the layered approach is understandable for defense in depth, extracting this common logic into a private helper method (e.g., setServerUrlVars($url)) would improve maintainability by reducing redundancy and ensuring consistency if this logic ever needs to be updated. This would make the code cleaner and easier to manage.

            $this->setServerUrlVars( $assoc_args['url'] );