-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add site health check to detect blocked REST API and short-circuit optimization when Inaccessible #1762
base: trunk
Are you sure you want to change the base?
Add site health check to detect blocked REST API and short-circuit optimization when Inaccessible #1762
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a plugin activation hook added as well which does add_option()
for the new option and then also kicks off (or schedules) a REST API check? Ideally there would be a warning shown immediately after activating the plugin (e.g. on the plugins list table screen) whether the REST API is working so that the user doesn't have to discover it later via Site Health.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe put site-health
in the root directory instead of inside includes
since there are no other directories in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought in future if we added something like admin dashboard for managing URL metrics or any other admin dashboard related thing then it would be better to add that feature in includes/admin
. But we can just refactor things later when we need it so moving site-health
to root makes sence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, let's put it in the root for now since all other directories are there.
if we added something like admin dashboard for managing URL metrics or any other admin dashboard related thing
Aside: I did put together a rough utility plugin for this: https://github.com/westonruter/od-admin-ui
'<p>%s</p>', | ||
esc_html__( 'The Optimization Detective endpoint could not be reached. This might mean the REST API is disabled or blocked.', 'optimization-detective' ) | ||
); | ||
update_option( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the first PR that adds an option to to Optimization Detective. We'll need to make sure that the relevant delete_option()
calls get added to the plugin's uninstall.php
.
// Disable detection if the REST API is disabled. | ||
$od_rest_api_info = get_option( 'od_rest_api_info' ); | ||
if ( is_array( $od_rest_api_info ) && isset( $od_rest_api_info['available'] ) ) { | ||
$needs_detection = (bool) $od_rest_api_info['available']; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this check wouldn't make sense here. It should rather be done in od_maybe_add_template_output_buffer_filter()
to short-circuit if the REST API it is not available.
update_option( | ||
'od_rest_api_info', | ||
array( | ||
'status' => 'error', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the $error->get_message()
and maybe $error->get_code()
be stored here?
update_option( | ||
'od_rest_api_info', | ||
array( | ||
'status' => 'forbidden', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of storing the string, what about storing the $status_code
instead?
'available' => false, | ||
) | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The else
condition should be added as an error result as well. Here especially the $status_code
could be used.
&& count( $expected_params ) === count( array_intersect( $data['data']['params'], $expected_params ) ) | ||
) { | ||
// The REST API endpoint is available. | ||
update_option( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of having update_option()
appearing in multiple places, each condition could populate an $info
variable which is then sent into update_option()
once at the end of the function.
wp_schedule_event( time(), 'hourly', 'od_rest_api_health_check_event' ); | ||
} | ||
} | ||
add_action( 'wp', 'od_schedule_rest_api_health_check' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a best practice? Should it rather go in admin_init
to avoid frontend writes? I'm not sure what others do here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think scheduling on plugin activation hook will be better than admin_init
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the plugin activation hook doesn't work when network-activating a plugin in multisite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In looking at WP_Site_Health
, it goes ahead and schedules an event even for frontend requests, since it calls its maybe_create_scheduled_event
method in the constructor. And the instance is loaded in wp-settings.php
. Nevertheless, since a database write is involved, it is preferable if event scheduling happens via an admin request and not unauthenticated frontend requests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please look at this comment regarding which hook should be used.
*/ | ||
function od_schedule_rest_api_health_check(): void { | ||
if ( ! (bool) wp_next_scheduled( 'od_rest_api_health_check_event' ) ) { | ||
wp_schedule_event( time(), 'hourly', 'od_rest_api_health_check_event' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think hourly is too much. Maybe weekly would make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I currently have it set to run weekly, but that might be too infrequent. If a configuration change disables the REST API, it could take an entire week for user to detect the issue. I believe running it daily would be a better choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think weekly is fine. It's not likely that a user would be changing the availability of the REST API. If we check at the moment that a plugin is activated, and then check weekly thereafter, then this should be good. Note that Site Health's own checks run on a weekly basis via the wp_site_health_scheduled_check
action.
// Omit the generator tag if the REST API is unavailable since in this case Optimization Detective is not generating anything on the page. | ||
if ( od_is_rest_api_unavailable() ) { | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felixarntz What do you think of adding this? This will avoid us querying pages from HTTP Archive using Optimization Detective which don't actually have it doing anything. This will improve our checks for efficacy rates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should omit the generator tag, as it's about indicating which sites use this plugin. If we want to mark sites which have or don't have the REST API available, we should do that with a separate mechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, what about appending this additional information at the end of the content, like 2a132ca
This is what the AMP plugin does: https://github.com/ampproject/amp-wp/blob/232df1cdf86bb76e1d7f885fbcf76f3ae6a67ebc/includes/amp-helper-functions.php#L886-L909
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would work!
As of 523daaa, the styling of the admin notices have been improved based on their context. Initially after activating the plugin: Subsequent page loads when only the inline admin notice is displayed after the user has expanded it: So the admin notice displayed at |
… add/site-health-check-for-od-rest-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to getting this out there!
Summary
Fixes #1731
Relevant technical choices
/optimization-detective/v1/url-metrics:store
REST API endpoint. The process will short-circuit if the endpoint is inaccessible.Scenarios:
When the health check passes
When the REST API endpoint returns a forbidden error
When the REST API endpoint returns an unauthorized error
When other errors are encountered