plugins_api() and parameters

[juliobox]

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:

<?php
require ABSPATH . 'wp-admin/includes/plugin-install.php';
$api = plugins_api(
        'plugin_information',
        array(
                '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:

<?php
object(stdClass)#1010 (32) {
  ["name"]=>
  string(37) "SecuPress Free — WordPress Security"
  ["slug"]=>
  string(9) "secupress"
  ["version"]=>
  string(7) "2.2.5.1"
  ["author"]=>
  string(44) "SecuPress"
  ["author_profile"]=>
  string(41) "https://profiles.wordpress.org/secupress/"
  ["contributors"]=>
  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 w.org since this is the site that add too much data and to not respect the passed parameters.

Thanks for your time

[audrasjb]

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

[dd32]

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:
​https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/standalone/class-plugins-info-api-request.php

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).

### Ticket: https://core.trac.wordpress.org/ticket/60783

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.

Changes

• 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.

[Rahe]

Hi,

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

<?php
"description" => true

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

For me it's working as expected.

Nicolas,

[rajinsharwar]

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.

[oglekler]

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.

[davidbaumwald]

With 6.7 Beta 1 releasing in a few hours, this is being moved to Future Release given a lack of recent momentum towards a resolution.

If any committer feels the remaining work can be resolved in time for Beta 1 or any other specific milestone and wishes to assume ownership during that cycle, feel free to update the milestone accordingly.

[SirLouen]

This report doesn't belong to this Core trac but to ​Meta trac.

Although ​the patch "solves" the issue, this is not an issue that must be solved in WP client but in the API endpoint… The user can always develop a workaround like the exhibited by this patch in his code. After all, it's client code (but the whole parameters are still being received by the client which is not what it is expected).

Replying to @juliobox

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).

Most fields, are not defaulted false, for example, ​sections, ​versions, ​reviews, ​contributors, etc… But the big list in the beginning can be a little confusing, making you think they are defaulted to false wrongly. Maybe they should rework it to leave things clearer.

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)

This must be reported on Meta trac because I cannot even see them filterable in the remote API request code.

This said, given that this report is a little old, I've done the report upstream already ​#7979, so this can be closed and continue the discussion there.