Documented `url` field cannot be use in `wp plugin search` command's `--fields` option

[yookoala]

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

According to the latest documentation and wp help plugin search, the --fields option support the field url, which should be the "Plugin's URL on wordpress.org".

In reality, if I add "url" to the --fields option, it will always show "Error: Invalid field: url.":

Same can be show for different plugin search

root@ae8caccf12cf:/var/www/html/wp-content/plugins# wp plugin search --fields=name,slug,url jetpack
Success: Showing 10 of 703 plugins.
Error: Invalid field: url.

Describe how other contributors can replicate this bug

Run a plugin search command like:

wp plugin search --fields=name,slug,url jetpack

Describe what you would expect as the correct outcome

A list of plugin with all the specified fields (include "url") to appear.

Let us know what environment you are running this on

OS:	Linux 6.17.5-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 23 15:35:13 UTC 2025 x86_64
Shell:	
PHP binary:	/usr/local/bin/php
PHP version:	8.1.33
php.ini used:	
MySQL binary:	/usr/bin/mariadb
MySQL version:	mariadb from 11.8.3-MariaDB, client 15.2 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:///usr/local/bin/wp-cli
WP-CLI packages dir:	
WP-CLI cache dir:	/root/.wp-cli/cache
WP-CLI global config:	/root/.wp-cli/config.yml
WP-CLI project config:	
WP-CLI version:	2.12.0

Provide a possible solution

Haven't dig into the code myself. Sorry.

Provide additional context/Screenshots

Website as of now:

Display of wp help plugin search:

Testing search command shows unexpected error:

[swissspidy]

Hi there, thanks for your detailed report!

Looking at https://developer.wordpress.org/reference/functions/plugins_api/ and https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request, then there is indeed no url field. Maybe it was there in the past & got removed. We should go through the list to remove the ones that aren't actually there.

Or maybe I'm also wrong and the error occurs because of our field validation: if one entry in the list doesn't have the required field but the others do, we still error.

[yookoala]

There are many of fields on the API endpoint response that are not documented anywhere. Even a 6 years old comment is more updated than the official function description above it. This is a serious issue with usability. Some sort of JSON schema should be maintained along with the API so other tools may draw that information and document accordingly.

Where should I report this? Is there anyway I can contribute to the API maintenance to add this schema?

I know this is not an issue of wp-cli, but I don't seem to find any straightforward answer anywhere about this.

[swissspidy]

https://meta.trac.wordpress.org/ Would be the place to report that. Not sure how public that particular code base is though.

[yookoala]

Opened a ticket here: https://meta.trac.wordpress.org/ticket/8124

Let's see what can be done there.

[yookoala]

The file responsible for the API endpoint is this file (current version). Will take a look at the source code to see if I can get it to serve a schema json.

[swissspidy]

Thanks! We can use that to update our documentation in the meantime.

[yookoala]

Further read the code. It seems the route is only for Plugin Directory. Not the JSON API endpoint for plugin information.

[swissspidy]

Just opened #474 now

[yookoala]

Actually I found a download_link field in the API that is quite useful for me.

One of the reason I want to see it is when I tried Fair PM, it is hard to know if the installation is successful or not. Checking the download_link made it clear to me that the plugin works.

[swissspidy]

Yeah that's the field we use for installing the plugins :)

[swissspidy]

@yookoala Turns out there was actually a bug in WP-CLI, as apparently the url field is something this command added on its own, but it didn't work with newer WP versions. #474 will fix that now.