One important thing that I have with WordPress is the default wp-cron.php implementation. If you are familiar with how WordPress uses wp-cron.php by default, you will probably change your mind after reading this article.
What is wp-cron.php & how does it work?
The wp-cron.php file is part of WordPress that handles scheduled events in a WordPress site. Anything related to the scheduling of posts or publications and really anything in a date / time orientation is governed by wp-cron.php file.
For wp-cron.php to work properly it needs to be executed regularly, but not more than once per minute. However, the default behavior does not require you to set up a real system-level cron job on your server. Instead, it uses the piggyback method on every incoming request. When a request comes to the website, WordPress makes an additional request from itself to the wp-cron.php file over HTTP (S). Sounds pretty innocuous, doesn’t it?
Why is it a nightmare to configure wp-cron.php by default?
The default method works perfectly fine on a small website with very few visitors per hour. However, when deployed on a medium or larger website or even a site that is being scanned by a bot (which is very common these days), this means you get any double which traffic you are dealing with. It becomes a rudimentary DDoS attack against yourself. This is because the cron is being executed multiple times per minute using an HTTP request. HTTP requests add overhead by creating, negotiating, and establishing a connection over a network socket. It even affects the efficient capacity of your underlying web server. This solution doesn’t work well in most situations and to be honest, it should be omitted as the default behavior due to the tendency to be misused or turn into a host attack vector from traffic alone. usually, common, normal.
Are there any alternatives?
The only real and effective alternative to configuring the system cronjob is to execute the wp-cron.php script directly through PHP code every minute. This ensures that all scheduled tasks are actually executed at their scheduled time. It should also not be done through an HTTP request but rather a direct PHP implementation to avoid obstructing the capacity of the web server or generating additional memory overhead on the network layer.
How do I disable the default wp-cron.php behavior?
This is quite common and simple to do. You need to update your wp-cronfig.php file as follows:
1 2 | define('DISABLE_WP_CRON', true); |
- You can usually find your wp-config.php file in your website’s public_html directory.
- This new setting will be placed in the file immediately after the DB_COLLATE database row that looks like the following
1 2 | define('DB_COLLATE', ''); |
How to set up system cronjob?
This is simple in cPanel, assuming your hosting provider has cron job enabled on your account. In cPanel Cron Jobs Documentation details about this issue, namely:
- Log in to cPanel from your domain: yourdomain.tld / cpanel
- Type “cron” in the quick search box near the top of the page.
- Click “Cron Jobs” icon.
- If it doesn’t appear, your account doesn’t have the Cron Jobs feature enabled and you’ll need to talk to your hosting provider for help setting up a cron or switch to a package that includes the Cron Jobs feature.
- Pay attention to the Cron Jobs page, which will give you the exact location of your PHP binary. You will need to copy that path into the command box at the bottom of the page and change the file being executed by PHP to your /home/username/public_html/wp-cron.php file. Use the full path.
- Select the first entry (“*”) for each parameter. This will execute the wp-cron.php file every minute.
- Click the add cron button and you’re done.
Why would you do this the hard way, does it seem logical, and there is an easier way to fix it?
I believe that our digital world software engineers must impress themselves with the sense of responsibility for their products. WordPress is popular today and with auto installers, like Softaculous, WordPress is installed on the majority of websites. They are installed with default behavior enabled, which is essentially an attack vector on any server. Now that the hosting industry is so popular in our lives, many people have WordPress websites and are unaware of this until it paralyzes their website. The default integration is very missing and needs to be removed. Today on one server alone, I found over 500 different WordPress installs and watched as a bot attacked each website on the server. Every one of those websites suddenly becomes a liability for the stability of the server.
I noticed that this issue is handled case by case. However, with so many installs around the world, WordPress would better deal with every single hosting provider having to set up special conditions on their servers to protect against vulnerabilities. that this software creates. The cost to get rid of this behavior and force the site owner to generate a system cronjob should be the basis and a notice is placed in the WordPress admin interface that scheduled tasks will not be executed until The system cronjob is properly created. This is in my programming skills, so I know it’s in their skills.
WordPress is all about ease of use, so their target customers are those who generally know little about hosting. I believe that the responsibility here is solely on WordPress to fix it and they came up with solutions to combat it. Meanwhile, sysadmins in the hosting industry endured this horrible “feature” of checking servers out of control due to a default setting of a bot running on WordPress.
Visualize madness
* Each visitor in wp-cron.php setup by default creates a secondary connection originating from the server over the network socket to wp-cron.php. Each visitor in this setup halves the overall available network sockets and increases a visitor’s load contribution to double that of a hit. The solution is running wp-cron.php via PHP via the regularly scheduled system cronjob. This eliminates the problem completely and, in my opinion, should be. to prevent overuse of default settings on WordPress website. * Source: https://medium.com/@thecpanelguy/the-nightmare-that-is-wpcron-php-ae31c1d3ae30