OK, this one is obscure. I only post about what I can’t find on Google!

Until recently it has been possible to run command-line PHP scripts that include wp-config.php or wpmu-settings.php, in order to give those scripts access to WordPress globals like $wpdb, functions such as wp_insert_post etc.

These scripts worked with WordPress-MU until recently — now the scripts just exit with no output.

The reason? WPMU now initiates a redirect in the bootstrap process (search for ‘header( “Location: “‘ in wpmu-settings.php). A browser can follow that redirection, but a command line script cannot. So, if you want to initiate scripts that run from the command line, you will have to get the web server involved by invoking a text browser such as curl, wget, or links.

It’s best not to force your scripts to figure out where to find wp-config.php anyway. I have taken to using a method suggested in this thread, as shown in the code sample below. The good news is, you know that your script will work the same whether initiated from a plugin in a graphic browser, used in an Ajax call, or initiated from cron or the command line shell.

So instead of kicking your script off with something like

/usr/bin/php -q myscript.php

You will create the script as a proper plugin and do something like

/usr/bin/curl -d mypp_cmd=status http://mywpmusite.com

Sample plugin code used for the above example follows. The prefix for the functions is ‘mypp’, which of course stands for ‘MY Plugin Prefix’ to create a unique namespace. The code below returns results as JSON encoded, and calls die()/exit() at the end to prevent an entire page being created. For log files run from cron, you may choose to return plain text instead.

  /**
   * Add a query var for this plugin
   * This allows Ajax programs to operate without requiring file paths
   * Instead, Ajax functions look for the query var 'mypp_cmd'
   */
  function mypp_query_vars($qvars) {
    $qvars[] = 'mypp_cmd';
    return $qvars;
  } // function mypp_query_vars
 
  /**
   * Handle AJAX requests in the template_redirect action
   * We recognize our requests from the query var 'mypp_cmd'
   * Here we allow GET requests using $_REQUEST; to restrict to POST, use $_POST instead
   */
  function mypp_template_redirect() {
    global $wpdb;
    $cmd = get_query_var('mypp_cmd');
    $response = array();
    if ($cmd) {
      switch($cmd) {
      case 'status':
	$response['status'] = array('success' => true,
				    'message' => 'Sample status message');
	break;
      default:
	$response['status'] = array('success' => false,
				    'msg' => 'Unknown command',
				    'cmd' => $cmd);
	break;
      } // switch $cmd
      header('Content-type: text/x-json; charset=utf-8');
      print utf8_encode(json_encode($response));
      die();
    } // $cmd is set
  } // function mypp_template_redirect
 
add_filter('query_vars', array($this, 'mypp_query_vars'));
add_action('template_redirect', array($this, 'mypp_template_redirect'));

When new web sites are generated by my client, I wanted the experience to be painless; a one-button ready-to-go web site.

It turns out there is an action hook (of course there is!) when a new blog is created.  So let’s get down to the nitty gritty and see how to implement it.

I wanted to create a property that would apply to the new web site, which would allow my client to limit what data gets displayed on that site.  I also wanted to generate the basic set of pages that I am using to support the sites’ URL structure.  Each page has a unique template that gives it some special navigation and content mojo.

So first I set the site-global option:

add_blog_option($blog_id, 
	        'campus_selection_criteria', 
                "CampusStateID LIKE '%'");

Now for the pages with their templates.  In order to let wp_insert_post know which blog to use, we use a handy function call:

switch_to_blog($blog_id);

We will also need to specify the theme we are using so that the starting theme will be selected and the templates will be correctly associated.

I can then create the pages as I would in Wordpress-non-MU.  The final step is to call add_action() to hook this code into the blog creation event.

Here is the code in its entirety

function dscp_initialize_blog($blog_id) {
   add_blog_option($blog_id, 
                   'campus_selection_criteria', 
                   "CampusStateID LIKE '%'");
   switch_to_blog($blog_id);
   // switch theme
   switch_theme('thematic', 'mychildtheme');
   $postdata = array('post_parent' => 0,
   'post_status' => 'publish',
   'post_title'   => 'DESCRIPTIVE TITLE',
   'post_name'  => 'descriptive-title', /* the slug */
   'page_template' => 'template-whatever.php',
   'post_type'   => 'page');
   $newid = wp_insert_post($postdata);
   if ($newid && !is_wp_error($newid)) {
      add_meta($newid);
   } else {
      // your error handling code
   }
}
 
add_action('wpmu_new_blog', 'dscp_initialize_blog');