MultiPHP hasn't been available to the masses for many years and as a result, many users still use PHP in a manner that is consistent with having only a single PHP version. An example is when a user executes a PHP script via cron like so:
Which PHP version is used if you specify only 'php' in the cron?
The default, primary PHP version is used. Given this, what happens when you have an old site set to use PHP 5.6, but you have a primary PHP version of PHP 7.3? The site uses PHP 5.6 but the cron will be executed with PHP version 7.3 unless you specify the full path to the PHP version's binary that the site is set to use (PHP 5.6).
In an attempt to anticipate how user's construct their crons, DirectAdmin added the following option in the directadmin.conf:
You can enable this by setting it to 1 like so:
/usr/local/directadmin/directadmin set set_php_bin_path_in_crons 1 restart
The default is for this to be disabled (set to 0).
When enabled, you will see the PHP PATH specified within the crontab. For example:
[root@host ~]# cat /var/spool/cron/* #direct_crons enabled. Safe to edit this file. DirectAdmin will update accordingly. PATH=/usr/local/php70/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/admin/.local/bin:/home/admin/bin * * * * * php -v >> ~/phpversion.log
As good of an idea that this is, problems can still arise. What if the user manually edits the path in a manner that would prevent DirectAdmin from recognizing it? DirectAdmin may not update it accordingly when the user uses the PHP Selector to change the PHP version. For this reason, one may recommend another to instead make sure to use the full PHP binary path in your crons instead, like so:
The disadvantage to this is that the PHP binary path would need to be manually updated in the cron anytime the site's PHP version is changed. Thus, an advantage to using the directadmin.conf option set_php_bin_path_in_cron is that at least an attempt to update the PHP version used in the cron is made automatically.
A restriction one should consider with set_php_bin_path_in_cron is that only a single PHP version can be specified for all of the user's crons across all of the user's domains. Whatever PHP version is in use for the user's main domain is the PHP version that is used for all of the user's domains' crons. You can use different PHP versions in the one user's crontab across their domains if you instead manually specify the full path to the desired PHP version's binary for each crontab entry.
Whether or not you choose to enable this option should be carefully considered against your server's configuration. For example, if you are a reseller with many, many users that are allowed to manage their own crons on a server that has several PHP versions enabled, it may be wise to enable the option but keep it in mind if a user complains of crons not working as they should.
If you have only a single PHP version installed on the server, and you have no intention to installing/using other versions, you may find it more sensible to leave the option disabled.
Feel free to open a support request with your KnownHost support team if you'd like us to enable this for you or if you have questions! :)