Access WordPress API Outside of WordPress (command-line PHP)

2 Views

I have a PHP script that I need to run as a cron job. However this script needs access to the WP API (get_pages(), get_post_meta() and get_permalink() specifically). I’ve followed the instructions at http://codex.wordpress.org/Integrating_WordPress_with_Your_Website, but to no avail.

Code:

Read More
require_once('../../../wp-blog-header.php');
$args = array(
    'child_of' => 2083
);
$pages = get_pages($args);

However when I run php -q this_file.php from the command-line I get the following output: 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Database Error</title>

</head>
<body>
    <h1>Error establishing a database connection</h1>
</body>
</html>

Anyone have any thoughts/suggestions?

Post Views: 2

Related posts

Leave a Reply

4 comments

  1. WordPress expects the $_SERVER variables to be setup as if it were a normal web request. Also, I would suggest loading wp-load.php instead of wp-blog-header.php since you probably don’t need the WP class or the template loader to run. Here is how I normally start any scripts I need to interact with WP from command line:

    define('DOING_AJAX', true);
define('WP_USE_THEMES', false);
$_SERVER = array(
    "HTTP_HOST" => "mysite.com",
    "SERVER_NAME" => "mysite.com",
    "REQUEST_URI" => "/",
    "REQUEST_METHOD" => "GET"
);
require_once('current/wp-load.php');

    Update 2018:

    Nowadays WordPress doesn’t require $_SERVER at all. If you simply need to access WordPress API functions (e.g. to read/write to the database), all you need is:

    require_once('current/wp-load.php');

# your code goes here...

  3. The accepted answer by @prettyboymp is about the most helpful and unique information about accessing wordpress from a php script that I have found on the web. It worked perfectly for me with WP core 3.7.1, then 3.9 broke it.

    The problem was that wp-load.php changed the way it tested the REQUEST_URI for a valid path. But fortunately it also added a new filter to allow short-circuiting the test.

    So to restore the functionality of the answer in 3.9, I added define('SUNRISE', 'on'); to wp-config.php, and created file wp-content/sunrise.php with this content:

    add_filter('pre_get_site_by_path', 'my_pre_get_site_by_path', 10, 5 /*null, $domain, $path, $segments, $paths*/ );
    function my_pre_get_site_by_path($input, $domain, $path, $segments, $paths) {
    if ($path == '/') {
        return get_blog_details(array('domain' => $domain, 'path' => PATH_CURRENT_SITE), false);
    }
    return $input;
}

  4. A variation to @prettyboymp’s answer could be:

    if(in_array(php_sapi_name(), ['cli', 'cli-server'])) {
    foreach($_SERVER as $key => $val) {
        if(!getenv($key))
             putenv($key.'='.$val);
    }

    if(!getenv('HTTP_HOST'))
        putenv('HTTP_HOST='.gethostname());

    if(!getenv('SERVER_ADDR'))
        putenv('SERVER_ADDR='.gethostbyname(gethostname()));

    if(!getenv('REQUEST_URI'))
        putenv('REQUEST_URI=/');

    if(!getenv('REQUEST_METHOD'))
        putenv('REQUEST_METHOD=GET');
}