WP API 1.2 endpoints don't work with latest WP core master

[mnelson4]

There seems to be a conflict between the WP API 1.2 plugin and the WP API code in latest core.
When the WP API 1.2 plugin is active, a request made to the index works fine, and lists the WP API 1.2 endpoints fine, but they all return 404 resopnses.

Eg a request to ​http://src.wordpress-develop.dev/wp-json/ returns

{
    "name": "admin",
    "description": "Just another WordPress site",
    "URL": "http://src.wordpress-develop.dev",
    "routes": {
        "/": {
            "supports": [
                "HEAD",
                "GET"
            ],
            "meta": {
                "self": "http://src.wordpress-develop.dev/wp-json/"
            }
        },
        "/posts": {
            "supports": [
                "HEAD",
                "GET",
                "POST"
            ],
            "meta": {
                "self": "http://src.wordpress-develop.dev/wp-json/posts"
            },
            "accepts_json": true
        },
...

but a request to
​http://src.wordpress-develop.dev/wp-json/posts returns

[
    {
        "code": "rest_no_route",
        "message": "No route was found matching the URL and request method",
        "data": {
            "status": 404
        }
    }
]

It was possible to have WP API 1.2 plugin and WP API 2.0 plugin active simultaneously (although you needed to add a few lines of code mentioned here: ​http://jrdk.nl/blog/2015/05/running-wp-api-1-2-2-0-beta-side-by-side/), so the plan is to have WP API 1.2 should work fine with the WP API in core right?
Ideally, folks using the WP API 1.2 should be able to continue using it with 4.4, using the same endpoints (ie maybe the index page should list endpoints from both WP API 1.2 and 2.0 when its active)

[mnelson4]

A quick-workaround for continuing to use the WP API 1.2 pluing is to just add this to functions.php or something:

add_filter( 'rest_enabled', '__return_false' );

which disables the WP API in core and allows 1.2 to continue working

[mnelson4]

hmmm nevermind; that seemed to only have worked temporarily. I think after permalinks got flushed I started getting

[
    {
        "code": "rest_disabled",
        "message": "The REST API is disabled on this site."
    }
]

on requests to src.wordpress-develop.dev/wp-json/

[mnelson4]

Adding this code snippet instead worked to keep WP API 1.2 running:

add_filter( 'rest_url_prefix', 'wp_api_change_url_prefix' );
function wp_api_change_url_prefix( $prefix ) {
	return 'wp-rest';
}

Has anyone ever suggested using 'wp-rest' as the default prefix in WP API v2 and what's in WP core now? It seems to me that would totally remove compatibility issues with v1 and would be better name for the rest api's endpoints. I suspect 'wp-json' is just a leftover from v1

[mnelson4]

Adding this chunk of code to the WP API 1.2 also resolved the issue (basically if the rest api in core doesn't handle the request, it lets WP API 1.2 take a stab at it. It's pretty hacky):

add_filter( 'rest_pre_serve_request', 'serve_request_instead_of_core_api', 10, 4 );
function serve_request_instead_of_core_api( $handled, WP_HTTP_Response $rest_response, WP_REST_Request $request, WP_REST_Server $rest_server ) {
	if( $rest_response->get_status() == 404 ) {
		

		/**
		 * Whether this is a XML-RPC Request.
		 *
		 * @var bool
		 * @todo Remove me in favour of JSON_REQUEST
		 */
		define( 'XMLRPC_REQUEST', true );

		/**
		 * Whether this is a JSON Request.
		 *
		 * @var bool
		 */
		define( 'JSON_REQUEST', true );

		global $wp_json_server;

		// Allow for a plugin to insert a different class to handle requests.
		$wp_json_server_class = apply_filters( 'wp_json_server_class', 'WP_JSON_Server' );
		$wp_json_server = new $wp_json_server_class;

		/**
		 * Fires when preparing to serve an API request.
		 *
		 * Endpoint objects should be created and register their hooks on this
		 * action rather than another action to ensure they're only loaded when
		 * needed.
		 *
		 * @param WP_JSON_ResponseHandler $wp_json_server Response handler object.
		 */
		do_action( 'wp_json_server_before_serve', $wp_json_server );
		
		// Fire off the request.
		$wp_json_server->serve_request( $GLOBALS['wp']->query_vars['rest_route'] );
		return true;
	} else {
		return false;
	}
}

[mnelson4]

So those're my 3 suggestions on how this can be solved (in my order of preference):

1. Have the REST API in core use the endpoints wp-rest instead of wp-json
2. Add my 3rd code snippet (which uses the rest_pre_serve_request filter) to the WP API 1.2 plugin (or some form of it)
3. Leave the incompatibility, but just tell users of the WP API 1.2 plugin to use the my 2nd code snippet (which uses the rest_url_prefix filter)

[danielbachhuber]

@mnelson4 I think we'll be able to get away with fixing this in WP-API v1.x. Can you ​take this branch for a spin to confirm the fix?

[mnelson4]

Yeah that fix in WP API 1.2 works too!
The only downside to that fix (same with my suggestions # 2) is that if you're using the WP API 1.2, you can only see the WP API 1.2 index contents, which is unfortunate for any API clients hoping to use the REST API in WP 4.4 core.

Is switching the REST url prefix to wp-rest an option? I realize any API clients using WP API 2 beta would need to adjust, but it's a better solution to this (it works with the existing WP API 1.2 plugin, and allows WP API 1.2 and WP 4.4's APIs to be used side-by-side) and IMO a better REST url prefix anyways (and if we're ever going to change it, now's the time, before 4.4 is released)

[danielbachhuber]

Replying to mnelson4:

Yeah that fix in WP API 1.2 works too!
The only downside to that fix (same with my suggestions # 2) is that if you're using the WP API 1.2, you can only see the WP API 1.2 index contents, which is unfortunate for any API clients hoping to use the REST API in WP 4.4 core.

Is switching the REST url prefix to wp-rest an option? I realize any API clients using WP API 2 beta would need to adjust, but it's a better solution to this (it works with the existing WP API 1.2 plugin, and allows WP API 1.2 and WP 4.4's APIs to be used side-by-side) and IMO a better REST url prefix anyways (and if we're ever going to change it, now's the time, before 4.4 is released)

You could switch the REST URL in your specific environment to let both APIs run side by side.

We'll release WP-API v1.2.4 for WP 4.4 compatibility.

[mnelson4]

You could switch the REST URL in your specific environment to let both APIs run side by side.

Ya that's just what folks will need to do. All clients will just need to have the URL customizable instead of hardcoding it.
Thanks!

[bkelleher]

So - for those who need to run it side by side (I know I am late to the party, but we manage 200+ WP sites and I still have a critical one running on WP 4.7 and WP-API 1.2), is it expected that we change the prefix on the plugin or in WordPress core?? Is there a customizable option/constant in wp-config where I can set this URL prefix instead of hacking core?

[bkelleher]

Replying to bkelleher:

So - for those who need to run it side by side (I know I am late to the party, but we manage 200+ WP sites and I still have a critical one running on WP 4.7 and WP-API 1.2), is it expected that we change the prefix on the plugin or in WordPress core?? Is there a customizable option/constant in wp-config where I can set this URL prefix instead of hacking core?

I ended up using that filter rest_url_prefix and it works fine. wp-rest is not considered a reserved word, but I think I can manage.