PHP disable_functions, without breaking WordPress

PHP disable_functions is an INI setting that blocks selected PHP functions from running. On shared hosting we already turn off the dangerous ones, so WordPress core keeps working. On a VPS you control the list yourself, and a careless block can stop a plugin that shells out for images or backups. Treat it as one layer of defense, not a full security product, and always test the site after you change it.

What shared hosting already disables

Our shared stack runs cPanel with LiteSpeed and CloudLinux LVE. The CageFS-aware PHP INI typically blocks exec, passthru, shell_exec, system, proc_open, and similar calls. WordPress core does not need those functions. Some backup plugins, image optimizers, and deploy helpers do, and on shared you work within the fixed list. On a VPS you choose the list, so you also own the breakage if a plugin depends on a blocked call.

open_basedir is related and easy to set too tightly. When it is wrong, sessions, zip extracts, or WP-CLI can fail even though disable_functions looks fine. Test the real site after any change. Avoid pasting a hardened php.ini from an old blog that disables functions your app still uses.

See the list the process actually uses

CLI PHP and the LiteSpeed PHP handler for the vhost are not always the same. Check both before you open a ticket about a cron job that fails only on the schedule.

php -i | grep disable_functions

That command shows the CLI view. For the site itself, use the cPanel MultiPHP INI Editor for that vhost, then load a temporary phpinfo page and remove it when you are done. Change the INI the web server reads if you need the block to apply to visitors and web cron.

When an app needs a shell function

If a plugin truly needs exec or a similar call, replace the plugin when you can, or allow only what you must and watch the account. disable_functions cannot limit a function to one plugin. A webshell that calls system() is why the list exists; an image tool that calls convert is why people clear it. Prefer plugins that use the Imagick extension instead of shelling out to /usr/bin/convert.

Login rate limiting is a separate control. Do not lock yourself out by stacking a long disable list and a new login plugin in one session without another browser still logged in.