WHMCS automatic updates blocked because allow_url_fopen is off: the fix

WHMCS silently stops checking for automatic updates when allow_url_fopen is disabled in PHP, and since this is a PHP-level directive, it often affects the whole account without any obvious error message in the WHMCS admin panel. Here is where the setting lives and the cleanest way to flip it without disrupting other accounts on the server.

Why WHMCS needs allow_url_fopen

WHMCS uses allow_url_fopen to make outbound HTTP requests for several functions: checking for software updates, communicating with payment gateways that do not use cURL, and calling certain module APIs. When the directive is off, PHP cannot open remote URLs as file streams, and WHMCS's update checker fails silently. You will not see an error in most cases; the system simply will not notify you that updates are available.

In 2026, WHMCS has expanded its use of cURL for most critical functions, so allow_url_fopen being off breaks fewer things than it did in older versions. However, automatic update detection is still one of them, and running WHMCS on an out-of-date version is a real security risk given how frequently billing software is targeted.

First: confirm this is actually the problem

Before changing any PHP settings, confirm the issue. In WHMCS admin, go to System Settings > General Settings > Updates. If the version check is failing, you may see a timeout or an inability to connect message. You can also check directly from the command line by looking at your PHP configuration for the web user on the WHMCS account:

php -r "echo ini_get('allow_url_fopen');"

If this returns 0 or empty, allow_url_fopen is off. Note that the CLI PHP configuration is separate from the web PHP configuration on most servers, so this is directional but not definitive. To check what PHP sees under the web server for a specific domain, create a temporary phpinfo file:

<?php phpinfo(); ?>

Upload it to the WHMCS directory temporarily, browse to it, and search for allow_url_fopen in the output. The "Local Value" column is what PHP is actually using for that directory. Delete the file immediately after checking.

Where to fix it on a cPanel server

On a cPanel server with EasyApache 4 (the standard in 2026), PHP configuration is layered: global defaults set in the PHP version's config file, domain-level overrides via a .user.ini file or a .htaccess directive, and account-level overrides managed through MultiPHP INI Editor in WHM.

The cleanest fix that does not affect other accounts:

Option 1: MultiPHP INI Editor in WHM (recommended for shared servers)

1. Log into WHM as root or reseller.
2. Navigate to Software > MultiPHP INI Editor.
3. Select the PHP version the WHMCS account is using.
4. Choose the domain (account) from the dropdown.
5. Find allow_url_fopen and set it to On.
6. Save. No server restart required.

This change applies only to that specific account and does not touch other accounts on the same server.

Option 2: .user.ini in the WHMCS directory

If you want to limit the change to the WHMCS installation directory specifically (rather than the whole account), add a .user.ini file in the WHMCS root directory:

allow_url_fopen = On

PHP picks this up automatically within one or two request cycles (controlled by the user_ini.cache_ttl directive, usually 300 seconds). This is the most targeted approach and does not require WHM access.

Option 3: Global php.ini change (not recommended on shared servers)

You can change the global allow_url_fopen setting by editing the PHP version's php.ini directly at the OS level, but this affects every account on the server. On a server hosting multiple client sites, enabling this globally introduces risk if any account is running code that could be exploited through the file stream URL wrapper. Use Options 1 or 2 instead.

Where to fix it on a Plesk server

On Plesk, PHP settings are managed per domain through the Plesk control panel:

1. Log into Plesk.
2. Go to Websites and Domains and select the domain running WHMCS.
3. Click PHP Settings.
4. Find allow_url_fopen in the list.
5. Change the value to On and save.

If the PHP Settings option is not visible, your Plesk account may not have permission to change PHP settings at the domain level. In that case, you need access to the server-level PHP configuration through the Server Management panel, or you can use the .user.ini approach described above.

After making the change

Once allow_url_fopen is enabled, return to WHMCS admin and force a manual update check under System Settings > Updates. You should now see the current version comparison and any available updates.

While you are in the server configuration: check that cURL is also enabled and functioning. WHMCS prefers cURL over allow_url_fopen for most operations, and having both enabled is the safest configuration. Verify cURL in the phpinfo output you checked earlier, or via command line:

php -r "var_dump(curl_version());"

If cURL is missing or disabled, that is a larger issue that may require installing the PHP cURL extension through WHM's EasyApache 4 or your server's package manager.

The security context

Some server hardening guides recommend disabling allow_url_fopen as a defense against certain types of remote file inclusion attacks. This is a legitimate consideration, but in 2026 this directive is less relevant as a security control than it was in older PHP versions, because modern PHP applications are far less likely to use it in a way that creates a remote file inclusion vector. The bigger risk on a WHMCS server is running an outdated version of WHMCS because update checks were silently failing. Enable it for the account, use the most targeted scope possible, and keep the software updated.

If you are running into a string of server configuration issues after updates, the post-reboot WHM and cPanel checklist covers the broader set of things that can go sideways on a cPanel server restart.

The bottom line

WHMCS stops detecting automatic updates when allow_url_fopen is off. Fix it at the account level using MultiPHP INI Editor in WHM, or drop a .user.ini file in the WHMCS root with allow_url_fopen = On. Do not change the global server setting unless you have a reason to, and verify the fix by forcing a manual update check in the WHMCS admin panel immediately after.