WP-CLI is an awesome command line tool to manage your WordPress installation. You can view plugin information, perform plugin or core updates and show the current cron tasks. This is great for both system administrators who don’t always have user accounts within WordPress as well as WP admins who don’t want to fire up a browser to perform these tasks.

Unfortunately, some hosts lock out certain commands from running for security reasons. Things like shell_exec and proc_open are usually on this list. PHP itself had an option called “Safe Mode”, which although it has been deprecated, shows that there was time when this was needed or at least requested by the community. In a perfectly setup system these commands don’t need to be disabled. If you know you have a perfectly setup system, this post isn’t for you. For the rest of us that think we might have a perfectly setup system but wouldn’t place bets on it because we’ve been on the web long enough to remember attack after attack after attack after attack after attack, this post might be for you. If you try to run WP-CLI on a system that has proc_open disabled you might get fatal error like this:

Warning: proc_open() has been disabled for security reasons

You might think to yourself, “well, I guess I can’t use WP-CLI then” and you’d actually be very wrong (or at least mostly very wrong). WP-CLI uses proc_open for a couple of things but most commands don’t use it at all. In fact, the command that uses it most is the help command and it only uses it to format the text on the screen (by piping over to less). I submitted a patch for this but it was rejected because it was considered an edge case which I respect. I listed the commands that require proc_open here but I’ll list them below, too.

1. wp db * – Absolutely everything in db depends on it
2. wp core download does unless you specify and pre-create --path so that still works. This could be changed over to use wp_mkdir_p possibly
3. wp post create --edit – Attempts to launch your editor which won’t work and there’s no way around that
4. wp rewrite structure requires it to launch wp rewrite flush but you can still manually invoke the latter command. (This is the only command I could find that uses the launch_self helper, too)
5. wp plugin delete requires it to delete the folder recursively and forcfully. Seems like the _rmdir from the core command could just be reused
6. wp plugin update requires it only if --version=dev is passed to it
7. wp help – Pipes to less on non-Windows systems

So two entire commands, db and help, two specific parameter versions, wp post create --edit and wp plugin update --version=dev and three broken unless you know the work around, wp core download, wp rewrite structure and wp plugin delete.

Most of the items above work, you just need to do some extra work, but it’s the last one that’s just weird. The entire help subsystem won’t work because they’re using a system call to format the text onto multiple pages. Let me say that again, almost all commands work, only the help system won’t. Luckily this is a relatively easy fix, just download the source, apply the patch and rebuild the phar.