WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 4 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:
PR Number:

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.

Change History (3)

#1 @iseulde
6 years ago

You could do this, which disables the check entirely, but there will still be a heartbeat connection.

remove_action( 'admin_enqueue_scripts', 'wp_auth_check_load' );
remove_filter( 'heartbeat_send',        'wp_auth_check' );
remove_filter( 'heartbeat_nopriv_send', 'wp_auth_check' );

#2 @iseulde
6 years ago

  • Keywords close added

Related: #26050

#3 @wonderboymusic
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

comment:1 seems like it has good steps to take - this conversation has been dead for 18 months

Note: See TracTickets for help on using tickets.