Why is the Ajax heartbeat included in my cached frontend pages? Is it OK to get rid of it?

by

I recently thought I’d protect a WP site’s /wp-admin folder with Apache’s basic auth to provide a crude but somewhat effective additional layer of security (as a second line of defense should the WP install accidentally go out of date or an exploit emerge).

However when I did this, I immediately noticed that the site’s cached front-end pages started showing the authentication dialog, too!

This appears to be because the Ajax heartbeat is being included in all the frontend pages:

var cnArgs = {"ajaxurl":"https:\/\/www.example.com\/wp-admin\/admin-ajax.php","hideEffect":"fade","onScroll":"no","onScrollOffset":"100","cookieName":"cookie_notice_accepted","cookieValue":"TRUE","cookieTime":"7862400",
"cookiePath":"\/","cookieDomain":".example.com","redirection":"","cache":"1"};

and

/* <![CDATA[ */
var pvcArgsFrontend = {"mode":"js","requestURL":"https:\/\/www.example.com\/wp-admin\/admin-ajax.php","postID":"5","nonce":"e0785f90be"};
/* ]]> */

I understand the heartbeat’s purpose in the backend and for users who are logged in, but it doesn’t seem to make sense to have this in the public frontend (and it’s obviously and needlessly messing with my password protecting my wp-admin directory.)

Can I safely unregister the script? Or is there a good reason why it is there?

1 Answer
1

No, it’s not okay to lock down or block access to wp-admin and/or it’s sub-directories. Not only you already mentioned this is a crude method, it could and most likely will break the site, depending on its theme/plugins.

The reason is that some plugin or themes depend on either admin-ajax.php or admin-post.php to accomplish some tasks. That’s why there are additional global variables in your source.

For example, the pvcArgsFrontend variable belongs to the Post View Counter plugin, which uses admin-ajax.php to update a post’s view count. If you block wp-admin, you know what happens.

Leave a Comment