If you have a WordPress site that is password protected with HTTP Basic Auth, then you may encounter problems with the WordPress cron failing to run. A workaround is to install the “WP Cron HTTP Auth” from here:
After you install and activate the plugin, go to “Settings->WP Cron HTTP Auth” and enter the HTTP Basic Auth credentials.
Quick way to find the wp-admin login slug on WordPress sites with iThemes Security or Solid Security installed:
|
1 |
wp option pluck itsec-storage hide-backend slug |
If the sub-name changes then try:
|
1 |
wp option get itsec-storage | grep slug |
For low traffic WordPress sites, the internal cron will not run on a reliable schedule resulting in missed jobs. For high traffic sites the internal cron can result in excessive cron runs. The solution is to disable the internal cron and setup an external cronjob at the operating system level.
To disable the internal cron add the following to wp-config.php:
|
1 |
define('DISABLE_WP_CRON', true); |
For the external cron you can use curl or wget, but my preference is wp-cli like this:
|
1 |
wp cron event run --due-now >/dev/null 2>&1 |
On a Plesk server this might look like:
|
1 2 3 |
export PATH=/opt/plesk/php/7.4/bin:$PATH; \ cd /var/www/vhosts/acme.com/httpdocs/; \ wp cron event run --due-now >/dev/null 2>&1 |
Recently worked a WordPress site where the admin dashboard was taking a minute or more to load. Tracked the problem to the “Updates Needed” section in the “WordFence” block displayed on the dashboard. The Updates Needed section calls the WordPress “wp_version_check()” function. This function, as part of building the data sent to wordpress.org with the update version check, calls the WordPress “count_users()” function. The “count_users()” function runs a query like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
SELECT COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` LIKE ?, false)), COUNT(NULLIF(`meta_value` = ?, false)), COUNT(*) FROM wp_usermeta INNER JOIN wp_users ON user_id = ID WHERE meta_key = ? |
The number of “COUNT(NULLIF” columns depends on the number of user groups. For a site with a small number of users and groups this query is not a problem. But for a site with over 100K users this query took over 100 seconds to run.
To fix the problem, we used “wp-cli” to disable the “Updates Needed” section in WordFence:
|
1 |
wp db query "update wp_wfConfig set val = 0 where name = 'notification_updatesNeeded';" |
Now the admin dashboard loads with no delay. This is a great example of the types of problems that come with scaling a WordPress site to large numbers of users.
If you are using WordPress with CloudFront and WordFence then some extra configuration is required. WordFence does blocking based on IP address but it will fail to determine the correct IP address when you have CloudFront and an Elastic Load Balancer in front of the site. The work around is to setup a cronjob that updates the list of trusted proxies in WordFence.
Here’s a simple script for the cronjob:
|
1 2 3 4 5 6 7 8 9 10 11 |
#!/bin/bash # get the list of proxies from AWS IPS=`curl -s http://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips | jq -r '.[][]'` # use wp-cli to update WordFence config in database cd httpdocs wp db query "UPDATE wp_wfconfig SET val = '$IPS' WHERE name = 'howGetIPs_trusted_proxies';" # remove the WordFence config cache so the new IPs will be read on next page load rm wp-content/wflogs/config-synced.php |
