Making WordPress.org

Opened 11 years ago

Closed 7 years ago

Last modified 7 years ago

#111 closed defect (bug) (fixed)

Improve error when running plugins_api() with invalid slug

Reported by: scribu's profile scribu Owned by: dd32's profile 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
7 years ago

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

#2 @dd32
7 years 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
7 years ago

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

#4 @dd32
7 years 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
7 years 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
7 years 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
7 years 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
7 years ago

Thanks Dion!

#9 @dd32
7 years 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
7 years 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
7 years 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
7 years 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
7 years ago

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

#14 @dd32
7 years ago

In 6483:

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

See #111

#15 @dd32
7 years ago

In 6486:

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

See #111

#16 @dd32
7 years ago

In 6487:

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

See #111

#17 @dd32
7 years ago

In 6488:

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

See #111.

#18 @dd32
7 years 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
7 years ago

In 6496:

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

See #111.

#20 @dd32
7 years 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
7 years 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.