Opened 8 months ago
Last modified 6 weeks ago
#60783 accepted enhancement
plugins_api() and parameters
Reported by: | juliobox | Owned by: | audrasjb |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Plugins | Keywords: | good-first-bug has-patch needs-testing changes-requested |
Focuses: | docs | Cc: |
Description
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
Change History (10)
#1
@
8 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
#2
@
8 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:
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).
This ticket was mentioned in PR #6611 on WordPress/wordpress-develop by snehapatil2001.
6 months ago
#3
- Keywords has-patch added; needs-patch removed
### 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.
#5
@
5 months ago
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,
#6
@
5 months 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
@
5 months 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.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
7 weeks ago
This ticket was mentioned in Slack in #core by stoyangeorgiev. View the logs.
6 weeks ago
#10
@
6 weeks ago
- Milestone changed from 6.7 to Future Release
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.
Thanks for the ticket, markking as
good-first-bug
for new contributors.