get_test_rest_availability() test should point to diffrent endpoint (where no current_user_can() check is made)

[szaqal21]

Using system cron, when wp_site_health_scheduled_check event is triggered there is no way to determine user (auth cookie isn't set this causes wp_get_current_user() return "empty" user) this scenario results REST API unavailable because /wp-json/wp/v2/types/post?context=edit endpoint does caps check

<?php
if ( 'edit' === $request['context'] && ! current_user_can( $obj->cap->edit_posts ) ) {
                        return new WP_Error(
                                'rest_forbidden_context',
                                __( 'Sorry, you are not allowed to edit posts in this post type.' ),
                                array( 'status' => rest_authorization_required_code() )
                        );
                }

Triggering Site Health from wp-admin (browser) works fine because user is authenticated by auth cookie.

get_test_rest_availability() should check endpoint where no caps check is made or ?context=edit should be removed to bypass caps check.

[SergeyBiryukov]

Related: #52104

[TimothyBlynJacobs]

The check including context is intentional because it allows us to determine whether Gutenberg will be able to function properly. In other words it tests that authenticated requests to the REST API work, and that query parameters are properly parsed and context evaluated.

This is probably one of the tests that should only be done in a "live" mode that @clorith mentions.

[TimothyBlynJacobs]

#52104 was marked as a duplicate.

[Clorith]

With [49334] the concept of skip_cron was added to tests. This, when set, will make sure that a test can only be ran when the request comes from a user navigating to the Site Health page, and not when a cron event runs. This sounds like the same use-case as discussed here.

That means that to resolve this, one would want to add 'skip_cron' => true, to the test registration, and also replicate the check for ​`skip_cron` check that is in the ​`WP_Site_Health::wp_cron_scheduled_check()` function to also look for this in ​direct tests runner section.

The rest test checks an authenticated context and so is unsuitable for
running from a system cron job which has no authenticated user.

This change skips the rest test when running from cron, fixing a false
positive from temporarily appearing in the dashboard widget.

Trac #52112

Trac ticket: https://core.trac.wordpress.org/ticket/52112

[hermpheus]

I can see an argument for changing the test context to ensure that the REST API works for non-authenticated users, but I also see an argument that it is more important to test that authenticated REST calls work, as is necessary for Gutenberg.

The patch attached above implements the skip_cron fix @Clorith outlines above to fix the false positive.

Thanks all.

[Clorith]

In 50939:

Site Health: Skip REST tests during scheduled events.

This change fixes a false positive that would appear during scheduled events, by only running the REST test when a user visits the Site Health page, meaning an active session is available.

The test checking if the REST API is available, includes a parameter for context=edit to make sure the block editor can function properly. This means a user session with editor capabilities is required for the test to pass, which is not the case during a scheduled event.

Props szaqal21, TimothyBlynJacobs, hermpheus.
Fixes #52112.