Доступ к WordPress API за пределами WordPress (командной строки PHP)

У меня есть PHP-скрипт, который мне нужно запустить как задание cron. Однако для этого скрипта требуется доступ к WP API ( get_pages() , get_post_meta() и get_permalink() ). Я выполнил инструкции по адресу http://codex.wordpress.org/Integrating_WordPress_with_Your_Website , но безрезультатно.

Код:

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

Однако, когда я запускаю php -q this_file.php из командной строки, я получаю следующий вывод:

 <!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> 

У кого-нибудь есть какие-то мысли / предложения?

Solutions Collecting From Web of "Доступ к WordPress API за пределами WordPress (командной строки PHP)"

WordPress ожидает, что переменные $ _SERVER будут настроены так, как если бы это был обычный веб-запрос. Кроме того, я бы предложил загрузить wp-load.php вместо wp-blog-header.php, поскольку вам, вероятно, не нужен WP-класс или загрузчик шаблонов для запуска. Вот как я обычно запускаю любые скрипты, которые мне нужно взаимодействовать с WP из командной строки:

 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'); 

Вы можете использовать команду wp-cli eval-file :

 @daily /usr/bin/wp --path=/path/to/wp/ eval-file /path/to/that_file.php 

Сначала загрузится среда WP, а затем запустите файл.

Принятый ответ by @prettyboymp – это самая полезная и уникальная информация о доступе к wordpress из скрипта php, который я нашел в Интернете. Он отлично работал для меня с ядром WP 3.7.1, затем 3.9 сломал его.

Проблема заключалась в том, что wp-load.php изменил способ проверки REQUEST_URI для допустимого пути. Но, к счастью, он также добавил новый фильтр для короткого замыкания теста.

Итак, чтобы восстановить функциональность ответа в 3.9, я добавил define('SUNRISE', 'on'); на wp-config.php и созданный файл wp-content/sunrise.php с этим контентом:

 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; } 

Вариантом ответа @ prettyboymp может быть:

 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'); }