Make WordPress Core

Opened 4 months ago

Last modified 4 weeks ago

#60783 accepted enhancement

plugins_api() and parameters

Reported by: juliobox's profile juliobox Owned by: audrasjb's profile audrasjb
Milestone: 6.7 Priority: normal
Severity: normal Version:
Component: Plugins Keywords: good-first-bug has-patch needs-testing changes-requested
Focuses: docs Cc:


Hello there, (running WP6.5+, might be useless to say)
By reading the doc for plugins_api() you can read that some fields are included or not in the response, the doc says "$fields: Array of fields which should or should not be returned." and then you have a list of fields, some true some false by default.
Let's try it, this is my simple request on my plugin on repo:

require ABSPATH . 'wp-admin/includes/plugin-install.php';
$api = plugins_api(
                'slug'   => 'secupress',
                'fields' => []

Since the doc says "@type bool $contributors Whether to return the list of contributors. Default false." I should not receive this field.
Let see the response:

object(stdClass)#1010 (32) {
  string(37) "SecuPress Free — WordPress Security"
  string(9) "secupress"
  string(7) ""
  string(44) "SecuPress"
  string(41) ""
  array(4) {

There is. Same for those params that are "false" by default but still included: "sections", "versions", "reviews", "banners", "active_installs" (I don't know for "group", can't get the thing).

Also there is one param that is not affected by the arguments passed and always returned: "num_ratings".

Finally there is some fields that are always returned where the doc can't help, I tried to use they array keys to cancel them, no chance, this is : "author', "author_profile" (those 2 may be forced, that's ok), "support_threads", "support_threads_resolved", "upgrade_notice", and "requires_plugin" (I know it's new, but don't forget it)

The patch may have to be done on since this is the site that add too much data and to not respect the passed parameters.

Thanks for your time

Change History (7)

#1 @audrasjb
4 months ago

  • Keywords good-first-bug added
  • Milestone changed from Awaiting Review to 6.6
  • Owner set to audrasjb
  • Status changed from new to accepted
  • Version trunk deleted

Thanks for the ticket, markking as good-first-bug for new contributors.

#2 @dd32
4 months ago

Just noting that the underlying API is fairly stable; but the default returned parameters differ between API endpoint requested (version + action), some are dependant upon one another, others will be returned no matter what the client specifies, some are dependant upon the WP version, etc

The API in question is bootstrapped by this code which manages the fields parameter:

The API may change in behaviour (including fields returned, and the format of them) if WordPress gracefully handles the new data (and in the case of extra fields, it's never an issue).

This ticket was mentioned in PR #6611 on WordPress/wordpress-develop by snehapatil2001.

2 months ago

  • Keywords has-patch added; needs-patch removed

### Ticket:

This PR addresses an issue where certain fields with default false values are still being displayed in the plugin API response, even when these fields are not specified in the arguments. The solution involves setting these fields to false by default in the arguments before making the API call.


  • Added a function set_default_false_fields to ensure fields with default false values are explicitly set to false in the $args object.
  • Hooked the set_default_false_fields function to the plugins_api_args filter to modify the arguments before making the API request.

#4 @oglekler
6 weeks ago

  • Keywords needs-testing added

#5 @Rahe
5 weeks ago


I've tested this patch and there is no additionnal field return if "fields" is empty.
If passing

"description" => true

I've only the description added, if using false the description is not returned.

For me it's working as expected.


#6 @rajinsharwar
4 weeks ago

  • Keywords changes-requested added

I have tested the patch as well, and now it's only returning the parameters set while calling the function.

Left some comments on the PR> I believe we can convert the new function to a private one instead as there is not much it to be a public one.

#7 @oglekler
4 weeks ago

  • Milestone changed from 6.6 to 6.7
  • Type changed from defect (bug) to enhancement

This issue is going into an enhancement instead of a bug fix. It looks like the original bug was with the documentation.

We have RC1 today, so, I am moving this ticket to the next milestone and changing its type.

Note: See TracTickets for help on using tickets.