Opened 11 years ago
Closed 9 years ago
#27119 closed defect (bug) (worksforme)
disabling wp_auth_check_load does not actually disable the auth check
Reported by: | lisota | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.8.1 |
Component: | General | Keywords: | close |
Focuses: | Cc: |
Description
Line 4021 of wp-includes\functions.php mentions that the wp_auth_check can be disabled by the following:
remove_action( 'admin_enqueue_scripts', 'wp_auth_check_load' )
I expected that this would remove the auth check hearbeat actions, but the auth-check keeps firing even with this action removed.
We are experiencing sever CPU utilization issues due to heartbeat actions in post editing screens and are looking to disable these where we can. We've isolated the problem to the heartbeat API. Our site is high traffic with many editors who spend at least 8 hrs per day in one or more post edit screens at all times.
It appears that the auth-check is still firing from a combo of post.js and heartbeat.js on post edit screens, likely driven by the refresh-post-lock.
To reproduce, add the remove_action mentioned above to functions.php. Open fiddler (or equivalent), then open a new post for editing. Watch the admin-ajax actions every 15 seconds, and you'll see that the auth-check is still firing.
You could do this, which disables the check entirely, but there will still be a heartbeat connection.