REST API Support

[hbarroso]

This PR will allows the Co-Authors-Plus plugin to serve REST services through the new WordPress 4.4 API feature.

Please refer to API.md file for the full documentation.

[mjangda]

coauthors/v1/author/{author_id}/{post_id}

Why do we include the author_id in the route rather than as a separate param? Should we have a matching GET endpoint to get authors for a post?

[hbarroso]

@mjangda That is a very rough route idea of what I wanted to do when I started. But I agree, it shouldn't need the author_id. Also I think it would be a good idea to also rename that route to post/{post_id} , in which we could add, get, remove multiple users from a post as parameter of array of elements.

[mdawaffe]

There's some whitespace issues here. Also, this variable is not used.

[mdawaffe]

Search Endpoint:

Why is this a POST request? A sort of similar WP-API request (listing posts by an author) is a GET:
GET /wp-json/wp/v2/posts?author={author_id}

What does existing_authors mean? Don't I want to search for existing authors?

[mdawaffe]

Post - GET endpoint:

Why does this require authorization? The authorship of posts is public.

[hbarroso]

does_coauthor_exists() and does_coauthor_email_exists() would read better as does_coauthor_exist() and does_coauthor_email_exist().

EDIT: actually, the name of does_coauthor_email_exists() is confusing. If it's passed a coauthor object, it can return false even when the email exists :) Is there a better name that describes what the function does?

Since it's only ever called like that once, should we just not bother with the second parameter? It could return false if the email doesn't exist, or the coauthor ID of the coauthor with that email if it does exist. Then we could do that secondary check in ->put_item() itself (or some other function).

I'm not sure if that's the best solution. Do you have any another suggestions?

I like your suggestion. I think, if we used that logic in more than one place it would be useful to put it inside a new method. But using the logic inside the->put_item() is suffice IMO. I've also updated the methods names to *_exist() in 0c4599a

[mdawaffe]

I've also updated the methods names to *_exist() in 0c4599a

Thanks. Is does_coauthor_email_exists() still a good name, then?

[hbarroso]

Thanks. Is does_coauthor_email_exists() still a good name, then?

Yes, I think changing to something like is_email_unique() would be more meaningful now.

[mdawaffe]

I suggest we refactor this method into two different methods. One for checking the post type and another for the actual permissions. This way the API can safely use the correct one without having to use extra parameters.

I agree, though it seems like one function to check if a user can set authors for a specific post, and a different one for if a user can set authors for posts of a specific type:
current_user_can_set_post_authors( $post_id ), which could be used almost everywhere
current_user_can_set_post_type_authors( $post_type ), which could be used in a few places.

Would that cover everything, do you think?

EDIT: but yes, a different PR makes sense.

[hbarroso]

current_user_can_set_post_authors( $post_id ), which could be used almost everywhere
current_user_can_set_post_type_authors( $post_type ), which could be used in a few places.

Would that cover everything, do you think?

I like that. But what about the part that checks for the user level?
Do mean, leave it inside the current current_user_can_set_authors as it is and use those two new methods as helpers inside as well? Or should we also refactor that code into a new method?

I'm talking about this code

        $current_user = wp_get_current_user();
        if ( ! $current_user ) {
            return false;
        }
        // Super admins can do anything
        if ( function_exists( 'is_super_admin' ) && is_super_admin() ) {
            return true;
        }

        $can_set_authors = isset( $current_user->allcaps['edit_others_posts'] ) ? $current_user->allcaps['edit_others_posts'] : false;

        return apply_filters( 'coauthors_plus_edit_authors', $can_set_authors );

This code doesn't depend on $post_id or $post_type.

[mdawaffe]

I'm talking about this code

That's the code I'm talking about too. It looks as though it's supposed to take into account post-specific capabilities but doesn't.

It seems like it should be a wrapper for either current_user_can( 'edit_post', $post_id ) and/or checking for the $post_type->caps->edit_others_posts capability, but it doesn't do either :) I'm not sure what the "right" thing to do here is - thoughts? We can leave the implementation to a different PR, though.

[hbarroso]

@mdawaffe Yeah, I'm not sure either. For the sake of keeping the PR more clean (regarding the API implementation) I'd suggest we refactor just that code into a different method so we don't need the $is_api_request and just use that new method. And then on a future PR we deal with this. What do you think?

[mdawaffe]

That makes sense to me.

[mattoperry]

Probably just need either (int) or sanitize_text_field here (not both)

[hbarroso]

Yes, it's redundant . I'll use (int) instead.

[mattoperry]

Hey guys -- I've had a look over this and added a couple very minor notes, but it looks generally good and I'm not sure I have a ton of additional notes beyond what @mdawaffe has added above. I think what I'd like to do here is to add this to the 3.3 milestone and test this in a couple of real-world situations ... there are also a couple of people on the VIP team I'd like to show this to.

[djouonang]

Hello I have been trying to use the wp rest api to pull data from local site to live wordpress site with use of shortcode. When i try to do the reverse that is to pull posts from live to local it works but when i change links to retrieve from local to live it does not display anything on the page. I already have the wp rest api installed on both sites. Below is my code:

function my_recent_posts_shortcode($atts){

$response = wp_remote_get( 'http://localhost/wordpress/wp-json/wp/v2/posts' );

if( is_wp_error( $response ) ) {

return;

}

$posts = json_decode( wp_remote_retrieve_body( $response ) );

if( empty( $posts ) ) {

return;

}

if( !empty( $posts ) ) {

$list = '';

foreach( $posts as $post ) {

$list .='

link. '">' . $post->title->rendered . '
';
}

return $list . '';

}

}

add_shortcode('recent-posts', 'my_recent_posts_shortcode');

[misfist]

I'm really confused about what the status of this is. The REST API code isn't in the being discussed here doesn't seem to be in any existing branch. Could someone shed some light?

[misfist]

Now that the REST API is in core, this has become even more important. Is there any update on this?

[emhoracek]

@misfist the branch seems to be here: https://github.com/hbarroso/Co-Authors-Plus/tree/add/rest-api-endpoints

[mikeselander]

@philipjohn @mjangda what's the plan for this PR and functionality? We have a client need for REST endpoints for coauthors plus and while this doesn't meet our need exactly, I'm curious what considerations are being made for coauthors plus usage in the REST API. Specifically related to returning post results via the REST API core endpoints.

[philipjohn]

This isn't a priority right now, but we will have a bunch of work starting on the plugin soon so might be able to get this looked at as part of that.

[misfist]

@philipjohn - How/why is making Co-authors Plus work with the REST API, which is now in core not a priority?

[philipjohn]

@misfist Having API endpoints would definitely be nice, but it's not crucial to the functioning of this plugin which would work just as well without them. There are benefits to having these API endpoints, but the priority is fixing existing bugs and other more frequently requested enhancements.