WordPress.org

Making WordPress.org

Opened 6 years ago

Closed 20 months ago

Last modified 20 months ago

#111 closed defect (fixed)

Improve error when running plugins_api() with invalid slug

Reported by: scribu Owned by: dd32
Milestone: Priority: high
Component: API Keywords:
Cc:

Description

Migrating from #wp20615:

Input:

$api = plugins_api( 'plugin_information', array( 'slug' => 'doesnt-exist' ) );

var_dump( $api );

Expected result:

WP_Error Object
(
    [errors] => Array
        (
            [invalid_slug] => Array
                (
                    [0] => Invalid plugin slug.
                )

        )

    [error_data] => Array
        (
            [invalid_slug] => 404;
        )
)

Actual result:

WP_Error Object
(
    [errors] => Array
        (
            [plugins_api_failed] => Array
                (
                    [0] => An unknown error occurred during the API request.
                )

        )

    [error_data] => Array
        (
            [plugins_api_failed] => N;
        )
)

PS: I have no idea what that 'N' is supposed to represent.

As nacin says, N; is a serialized null. But we could improve the error message.

Change History (21)

#1 @obenland
20 months ago

@dd32 Is this something that is easier to do now?

#2 @dd32
20 months ago

@obenland This is a core thing, not really an API thing. The API can't be changed as core (and perhaps other clients) expect null to mean error.

For reference, here's what the current endpoints return:
https://api.wordpress.org/plugins/info/1.1/?action=plugin_information&request[slug]=404-does-not-exist

We can change the API to return something else instead of N; /null however doing so will cause WordPress itself to break. I've re-opened #wp20615 for that reason.

However, Core is not currently using the 1.1 API (It's still using the 1.0 api) so what we can do is change the 1.1 error responses (I don't really care about non-WordPress clients in this case) so that when core is shifted to 1.1 it's error handling gets fixed at the same time.

#3 @tellyworth
20 months ago

  • Owner set to dd32
  • Priority changed from low to high
  • Status changed from new to assigned

#4 @dd32
20 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 6422:

Plugin Directory: API: Return a proper error message for api.wordpress.org/plugin/info/ when the plugin cannot be found.
WordPress itself expects the null response, and currently uses the info/1.0 endpoint which returns PHP, so we'll retain this carveout for it.

These URLs now return an error message:
https://api.wordpress.org/plugins/info/1.0/non-existant-plugin.json
https://api.wordpress.org/plugins/info/1.0/non-existant-plugin.xml
https://api.wordpress.org/plugins/info/1.1/?action=plugin_information&request[slug]=non-existant-plugin

Fixes #111.

#5 @afragen
20 months ago

For consistency this probably should be changed in the query for themes too.

FWIW this did cause me a breaking change to a plugin :(

#6 @dd32
20 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

As this broke client expectations, I'm going to revert this and push it out as a 1.2 api instead - with the intention that we also update WordPress 5.0 to use the 1.2 API going forward as well.

#7 @dd32
20 months ago

In 6455:

Plugin Directory: Revert [6422] due to it breaking some clients which relied upon the null behaviour in the json endpoints too.

See #111

#8 @afragen
20 months ago

Thanks Dion!

#9 @dd32
20 months ago

In 6463:

Plugin Directory: API: Introduce a info/1.2 api endpoint which drops the backwards-compatibility for non-existant plugins.

Example: https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=404-plugin

See #111

#10 @dd32
20 months ago

In 6464:

Plugin Directory: API: rejig how the error handling in [6463] is handled - The old behaviour is now only present if the constant is defined as false.

See #111

#11 @dd32
20 months ago

In 6465:

Theme Directory: API: Add an info./1.2 endpoint which returns real errors in the event a theme cannot be found.

Back-compat behaviour for info/1.0 and info/1.1 is to return false in the event a theme cannot be located.

See #111

#12 @dd32
20 months ago

Going to mark this as completed.

FYI info/1.2 for both Themes and plugins should be considered alpha until such a time that a WordPress release uses them. That'll most likely be the WordPress 5.0 release, but check #wp20615.

Some changes may be made to the response format as needed, for example, having a different default result set.

#13 @dd32
20 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

#14 @dd32
20 months ago

In 6483:

API: Theme Directory: Disallow POST requests to the info/1.2 api endpoint.

See #111

#15 @dd32
20 months ago

In 6486:

API: Plugin & Theme Directory: Use the new constants to determine which API version we're running on.

See #111

#16 @dd32
20 months ago

In 6487:

API: Plugin Directory: In the info/1.2 API default to sending a more complete contributors response.

See #111

#17 @dd32
20 months ago

In 6488:

API: Theme Directory: In the info/1.2 API default to sending a more complete author response.

See #111.

#18 @dd32
20 months ago

In 6489:

Theme Directory: API: In info/1.2 do not vary the response of feature_list based on the UA, only explicit GET variables.

See #111

#19 @dd32
20 months ago

In 6496:

Plugin Directory: API: Update the list of fields included by default in the info/1.2 endpoint.

See #111.

#20 @dd32
20 months ago

In 6497:

Theme Directory: API: Update the list of fields to include by default in teh info/1.2 API endpoints.

See #111.

#21 @dd32
20 months ago

In 6499:

Theme Directory: API: Add user_nicename back into the extended_author details, turns we we do actually use that.

See #111.

Note: See TracTickets for help on using tickets.