Implement wp site get command to enable site operations by URL

[Copilot]

Multisite installations with custom domains couldn't easily delete sites by URL - only by ID or slug, which required manual lookup in automated workflows.

Implementation

Adds wp site get <site> command that accepts both site IDs and full URLs:

URL detection and lookup

• Uses is_numeric() to distinguish between site IDs (numeric) and URLs/domains (non-numeric)
• Automatically normalizes URLs without scheme by prepending http://
• Parses URLs via wp_parse_url() to extract domain and path
• Uses WordPress's cached get_blog_id_from_url() function for efficient lookups
• Supports flexible input formats:
  • Numeric site IDs: 2
  • Full URLs: http://example.com/site1/
  • Domains with paths: example.com/site1
  • Simple domains: example.com
  • Subdomains: subdomain.example.com

Output formatting

• Returns site details via WP_CLI\Formatter with standard format options
• Default fields: blog_id, url, last_updated, registered
• Optional fields: site_id, domain, path, public, archived, mature, spam, deleted, lang_id
• Supports --field parameter for single field extraction

Command registration

• Added to composer.json commands list

Usage

# Get site ID from URL (with or without scheme)
$ wp site get example.com/subdir/ --field=blog_id
2

$ wp site get http://example.com/subdir/ --field=blog_id
2

# Delete site by URL
$ wp site delete $(wp site get example.com/subdir/ --field=blog_id) --yes
Success: The site at 'http://example.com/subdir/' was deleted.

Test Coverage

Added comprehensive Behat test scenarios covering:

• Site lookup by numeric ID
• Site lookup by full URL with scheme
• Site lookup by URL without scheme
• Site lookup by domain with path (no trailing slash)
• Site lookup by subdomain without scheme
• Main site lookup by domain only
• Error handling for invalid/non-existent URLs

All 32 test scenarios pass (372 steps).

Follows the pattern established by wp user get and wp post get for consistency with existing commands.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>site delete: allow deleting a site with the --url option</issue_title>
<issue_description>## Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Currently the blog ID or slug must be specified when using the command. In cases where a custom domain is used, however, the --slug option fails and it is tedious to look up the assigned site ID in an automated use case.

Describe the solution you'd like

Allow site deletion by only specifying the --url option. For example: wp site delete --url="http://example.com".
</issue_description>

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

@swissspidy We could implement `wp site get ` instead, then one could pair `wp site delete` with `wp site get http://example.com --field=id`. This would be more in line with all the other commands.

• Fixes site delete: allow deleting a site with the --url option #506

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[codecov]

Codecov Report

❌ Patch coverage is 93.54839% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Site_Command.php	93.54%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[swissspidy]

/gemini review

[gemini-code-assist]

Code Review

The implementation of wp site get is a solid addition that fulfills the requirement of fetching site details by URL. The code is well-structured, follows WP-CLI conventions, and includes comprehensive Behat tests. I've suggested a more robust way to detect URLs to support domain-only inputs and ensure a smoother user experience.

[swissspidy]

@copilot increase test coverage

also:

The current URL detection logic is a bit restrictive as it only recognizes strings containing :// or starting with www.. This means a simple domain like example.com or a subdirectory path like example.com/site1 would be treated as a site ID and likely fail. Since site IDs are always numeric, a more robust approach is to treat any non-numeric argument as a potential URL or domain.

		// Check if the argument is a URL or a domain (non-numeric)
		if ( ! is_numeric( $site_arg ) ) {
			// Normalize URLs without a scheme for proper parsing.
			$url_to_parse = $site_arg;
			if ( false === strpos( $url_to_parse, '://' ) ) {
				$url_to_parse = 'http://' . $url_to_parse;
			}

[Copilot]

@copilot increase test coverage

also:
...

Implemented! Changed URL detection to use is_numeric() check, allowing simple domains like example.com and paths like example.com/site1 to be recognized as URLs. Added 4 new test scenarios covering:

• Domain without scheme (e.g., example.com/noscheme/)
• Simple domain path without trailing slash (e.g., example.com/simplepath)
• Subdomain without scheme (e.g., subdomain.example.com)
• Main site by domain (e.g., example.com)

All 32 site.feature scenarios now pass. (47d921e)

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 5bc373.example.com
  • Triggering command: /usr/bin/php /usr/bin/php /home/REDACTED/work/entity-command/entity-command/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php core install-network --title=WP CLI Network --subdomains=1 (dns block)
• 9303d9.example.com
  • Triggering command: /usr/bin/php /usr/bin/php /home/REDACTED/work/entity-command/entity-command/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php core install-network --title=WP CLI Network --subdomains=1 rue ); } om/wp-cli/entity-command (dns block)
• a4327e.example.com
  • Triggering command: /usr/bin/php /usr/bin/php /home/REDACTED/work/entity-command/entity-command/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php core install-network --title=WP CLI Network --subdomains=1 install-network e --subdomains=0 create /entity-command/core sh vend�� k/entity-command--subdomains=0 list /bin/sh site deactivate /home/REDACTED/.cocore sh (dns block)
• example.com
  • Triggering command: /usr/bin/php /usr/bin/php /home/REDACTED/work/entity-command/entity-command/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php core install --url=REDACTED --title=WP CLI Site --admin_user=admin --admin_email=admin@example.com --admin_password=password1 --skip-email (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)