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
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.
wp db *– Absolutely everything in
dbdepends on it
wp core downloaddoes unless you specify and pre-create
--pathso that still works.
This could be changed over to use
wp post create --edit– Attempts to launch your editor which won’t work and there’s no way around that
wp rewrite structurerequires it to launch
wp rewrite flushbut you can still manually invoke the latter command. (This is the only command I could find that uses the
wp plugin deleterequires it to delete the folder recursively and forcfully. Seems like the
corecommand could just be reused
wp plugin updaterequires it only if
--version=devis passed to it
wp help– Pipes to
lesson non-Windows systems
So two entire commands,
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.