Running WordPress commands in the shell

Every so often I quickly need to check the output of a particular WordPress function. You can do this by inserting some logging calls into the WordPress file you’re looking at, calling a page that executes the function you’re looking for, and then perusing your logs, and sometimes that’s really what’s needed.  But often you don’t need anything nearly so effort-intensive.

Case in point, in tracking down a problem with the MailPress plugin today wherein email addresses that have a “.” in the pre-“@” part (the local-part, in RFC2822) were being rejected by MailPress, one of the MailPress forum participants claimed that the issue was being caused by the fact that the WordPress function is_email() returns false for addresses where the local-part contains a “.”.  I did not believe that to be true and wanted to see the actual output of the code without having to jump through al of those hoops.  Luckily there’s a wquick and dirty way to do this leveraging the wp-load file in your WordPress root and the interactive PHP shell.

To get into the interactive PHP shell type

php –a

at your shell and you should be dropped into the PHP interactive mode, where you can type php code and have it executed as it is typed. Usually you shell prompt will then look like this

php>

Once there you need to import the WordPress architecture, and using the wp-load functionality that’s really easy. Just execute

require_once(‘wp-load.php’);

and your PHP environment will now have access to the whole WordPress code-base. From there I could type

var_dump(is_email(‘.@.com’)); 

and receive

bool(false)

in return, so is_email() is catching obviously bad emails. Executing

var_dump(is_email(‘an.email.with.dots@gmail.com’));

returns

string(28) “an.email.with.dots@gmail.com”

showing that is_email() correctly recognizes that email.

Things to keep in mind:

  1. You won’t have the full WordPress context that’s generated by executing the PHP script in the browser – you’ll have no current_user, no Loop, and no other WordPress context unless you create it yourself.
  2. fatal php errors will kick you all the way out of the PHP shell, losing your carefully constructed context, so this mechanism probably isn’t suited to cases where you have to set up a big context to look at what you want to look at. This is suited for isolated functions that rely on nothing but the parameters passed in, but not for much that’s more complicated than that.