WordPress как на ладони
wordpress jino

HTTP API WordPress

В PHP есть несколько способов отправить HTTP запрос, в WordPress только один. Но этот один способ включает в себя все варианты поддерживаемые PHP - это и есть API, это стандарт и это удобно!

Короткое знакомство с HTTP API

Для совсем новичков, пожалуй стоит пояснить, что такое HTTP запрос. Это запрос браузера к серверу, или одного сервера к другому, где происходит подобный диалог:

  1. Привет сервер, можешь мне показать файл: file.html?
  2. Привет! Могу, вот он...

Выглядит такой диалог вот так (только на месте клиента в данном случае выступает наш сервер, который делает запрос на другой сервер):

ch-negotiation

При создании HTTP запросов в PHP, как правило используются один из вариантов: библиотека cURL или встроенные в PHP потоки (streams). Чтобы упростить и стандартизировать разные способы отправки запросов, с версии 2.7. в WordPress появился класс WP_Http, который и лег в основу HTTP API.

С версии WP 4.6 ядро WP_Http полностью заменили PHP библиотекой Requests for PHP и теперь все запросы выполняются через нее. Вышеупомянутые классы WP_Http_Curl и WP_Http_Streams уже не используются. Таким образом, технически HTTP API WordPress кардинально изменился, но остался прежнем внешне: все работает как и работало. Также, с внедрением библиотеки Requests ожидаются новые возможности, некоторые из них уже появились (нечувствительные к регистру заголовки, поддержка международных доменов вроде böcean.ch), а другие (параллельные запросы) появятся в следующих релизах и пока возможны только с использованием библиотеки Requests напрямую.

Устарело с WP 4.6. WP_Http определяет тип транспорта, и вызывает другой класс соответствующий этому типу. Вызванный класс создает сам запрос. По умолчанию в WordPress два таких класса, для разных типов: WP_Http_Curl и WP_Http_Streams

Удобство и необходимость такого API заключается в том, что разные хостинги поддерживают разные варианты отправки запросов, а некоторые не поддерживают ни один. Задача HTTP API создать единый стандарт использования запросов в WordPress, при этом чтобы запросы работали всегда, если не поддерживается один способ транспортировки запроса, то будет найден альтернативный.

Другая задача - упростить разработку. Авторам плагинов приходится писать кучу кода, изобретать велосипеды и допускать ошибки. И все это, чтобы их плагин умел работать с любым хостингом. С HTTP API эта задача должна упроститься до нескольких встроенных в WordPress функций.

Еще один плюс HTTP API в том, что мы имеет единый стандарт указываемых данных, при работе с разными типами транспортировки запросов, т.е. мы всегда указываем одинаковые параметры и передаем их в функцию HTTP API, а класс уже выбирает подходящий тип транспорта, например cURL, изменяет наши параметры под понятные для текущего типа транспорта, и отправляет запрос.

С версии 2.7. HTTP API работал только с базовыми элементами запроса: header, body и response. С версии 2.8. появились: сжатие (compression), куки (cookies) и поддержка прокси (proxy). Некоторые из функций пассивные, т.е. работают автоматически, без установки дополнительных параметров запроса.

HTTP API WordPress сегодня - это полноценное API, в котором учтены многие мелочи и исправлены сотни ошибок. Также следует заметить, что до версии WP 4.4 HTTP API значительно отличался от того какой он сейчас, поэтому некоторые моменты из этого мануала могут не работать на версиях до 4.4.

Почти все возможности транспорта, можно изменять через опции или фильтры. Например, через фильтр http_api_transports можно добавить еще один, свой класс транспорта. Или через установку констант в файл wp-config.php можно включить режим прокси:

define('WP_PROXY_HOST', '192.168.84.101');
define('WP_PROXY_PORT', '8080');
define('WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com, *.wordpress.org');

Чтобы разобраться, как работает прокси смотрите класс WP_HTTP_Proxy{}

Ну, и наконец, HTTP API можно без особого труда расширить, для работы с Twitter API, Google Maps API и т.д.

Функции HTTP API и отправка запроса

Использовать HTTP API очень просто, для этого существуют специальные функции API:

Функции отправки запросов:

  • wp_remote_get( $url, $args ) – отправляет HTTP GET запрос.

  • wp_remote_post( $url, $args ) – отправляет HTTP POST запрос.

  • wp_remote_head( $url, $args ) – отправляет HTTP HEAD запрос.

  • wp_get_http_headers( $url ) - получает только HTTP заголовки указанного URL.

  • wp_remote_request( $url, $args ) – отправляет запрос любого типа: GET, POST, HEAD, PUT, DELETE.

  • wp_safe_remote_request( $url, $args ) - то же что и wp_remote_request(), только $url очищается от опасных символов для предотвращения хакерских атак. Нужно при HTTP запросах на заранее неизвестные URL, например, когда URL передается динамически. Для «safe» также есть функции обёртки:

    • wp_safe_remote_get( $url, $args )
    • wp_safe_remote_post( $url, $args )
    • wp_safe_remote_head( $url, $args )

Функции получения ответа на запрос:

Параметры функций

$url(строка) (обязательный)
URL куда будет отправлен запрос (с которого будут получены данные).
$args(массив)
Параметры запроса. Список параметров смотрите в описании wp_remote_request()
По умолчанию: array() (предустановки)
$response(массив)
Результат запроса возвращаемый любой функцией запроса.

Теперь, когда мы знаем все функции запросов, давайте попробуем создать простой запрос.

$response = wp_remote_get('http://httpbin.org/get?a=b&c=d');

Тут, мы отправили запрос на URL: http://httpbin.org/get и добавили два параметра запроса ?a=b&c=d. В результате, $response будет содержать следующий массив:

Array (
	[headers] => Array (
			[server] => nginx
			[date] => Sun, 19 Jun 2016 08:18:20 GMT
			[content-type] => application/json
			[content-length] => 316
			[connection] => close
			[access-control-allow-origin] => *
			[access-control-allow-credentials] => true
		)

	[body] => {
		"args": {
			"a": "b", 
			"c": "d"
		}, 
		"headers": {
			"Accept": "*/*", 
			"Accept-Encoding": "deflate;q=1.0, compress;q=0.5, gzip;q=0.5", 
			"Host": "httpbin.org", 
			"User-Agent": "WordPress/4.5.2; http://wp-kama.ru"
		}, 
		"origin": "5.101.156.80", 
		"url": "http://httpbin.org/get?a=b&c=d"
	}

	[response] => Array (
			[code] => 200
			[message] => OK
		)

	[cookies] => Array()

	[filename] => 

	[http_response] => WP_HTTP_Requests_Response Object (
		...
	)
)

Как видно, результат содержит ключи, каждый ключ - это часть ответа сервера, где:

  • headers - содержит заголовки HTTP ответа сервера.
  • body - тело ответа. Если мы запрашиваем html страницу, то тут будет HTML код. Если возвращаются JSON данные, то тут будет JSON строка. И т.д.
  • response - содержит статус код HTTP ответа. Например 200 - OK.
  • cookies - содержит куки, которые просит установить сервер в ответе на запрос.
  • filename - содержит расположение или путь файла который был отправлен на сервер и был там размещен. Файл можно отправить POST запросом.
  • http_response - с версии WP 4.6. Cодержит весь объект результата запроса библиотеки Requests.

Каждую часть ответа можно получить выбрав её из массива. Например, давайте получим заголовки ответа:

$response = wp_remote_get('http://httpbin.org/get?a=b&c=d');
$headers = $response['headers'];

echo $headers['server']; //> nginx
echo $headers['content-type']; //> application/json
echo $headers['content-length']; //> 316

Однако, получать части ответа таким образом не рекомендуется! Потому что ответ может быть разный и его нужно проверить или как-то дополнительно обработать.

Для получения каждой части ответа рекомендуется использовать специальные функции указанные выше. Давайте получим нужные нам заголовки ответа правильно:

$response = wp_remote_get('http://httpbin.org/get?a=b&c=d');

echo wp_remote_retrieve_header($response, 'server'); //> nginx
echo wp_remote_retrieve_header($response, 'content-type'); //> application/json
echo wp_remote_retrieve_header($response, 'content-length'); //> 316

На этом теоретическую часть HTTP API можно закончить и перейти к практике, точнее к примерам.

Примеры запросов на базе WordPress HTTP API

#1 Передача параметров запроса в GET и POST

Для POST запроса параметры передаются в настройке body:

$url = 'http://httpbin.org/post';

// параметры запроса
$body = array(
	'foo' => 'значение 1',
	'bar' => 10
);

// настройки запроса
$args = array(
	'body' => $body,
	'timeout' => '5',
);

$response = wp_remote_post( $url, $args );

Для GET запроса аргументы передаются в самом URL:

$url = 'http://httpbin.org/get';

// параметры запроса
$params = array(
	'foo' => 'значение 1',
	'bar' => 10
);

// чтобы кириллица правильно передалась
$params = urlencode_deep( $params );

// Добавим параметр в URL
$url = add_query_arg( $params, $url );

// в результате получим такой URL: 
// http://httpbin.org/get?foo=%D0%B7%D0%B0%D0%BD%D1%87%D0%B5%D0%BD%D0%B8%D0%B5+1&bar=10

// отправляем запрос
$response = wp_remote_get( $url );

$body = wp_remote_retrieve_body( $response );

print_r( $body );

#2 Изменение настроек запроса

Перед отправкой запроса, можно изменить дефолтные настройки запроса. Например, установить timeout (максимальное время) соединения или указать user agent.

Полный список параметров (настроек) смотрите в описании wp_remote_request().

А этот пример демонстрирует, как передавать такие настройки:

$url = 'http://httpbin.org/get';

$args = array(
	'timeout' => 5, // Время в секундах на получение данных.
	'user-agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36',
);

$response = wp_remote_get( $url, $args );

#3 Получение тела ответа (наше любимое)

Этот пример показывает как передать в запрос дополнительный заголовок и получить тело (текст) ответа.

$url = 'http://httpbin.org/get?a=b&c=d';

// Передача заголовка в данном случае смысла не имеет - это просто демонстрация.
$args = array(
	'headers' => array( "Content-type" => "application/json" )
);

$response = wp_remote_get( $url, $args );

$body = wp_remote_retrieve_body( $response );

#4 Получение заголовков ответа

#1 Делаем полный запрос и получаем из него заголовки

Этот пример показывает как сделать полный запрос, но получить только заголовки ответа:

$response = wp_remote_get('http://httpbin.org/get?a=b&c=d');

// получаем только заголовки ответа
$response_headers = wp_remote_retrieve_headers( $response ); //> массив со всеми заголовками

// получаем отдельный заголовок ответа
$content_type = wp_remote_retrieve_header( $response, 'content-type' ); //> application/json
#2 Запрашиваем только заголовки

В этом примере мы не будем создавать полный запрос, а запросим только заголовки. Для этого воспользоватся функцией запроса wp_remote_head():

$response = wp_remote_head('http://httpbin.org/get?a=b&c=d');

$response_headers = wp_remote_retrieve_headers( $response ); //> массив со всеми заголовками

Ответ на такой запрос мы получим быстрее, чем при «полном запросе». Поэтому, если вам не нужно тело ответа, то пользуйтесь таким запросом.

#3 Запрашиваем только заголовки (способ 2)

Используя функцию wp_get_http_headers(), мы также можем не создавать полный запрос, а запросить и сразу получить только заголовки:

$response_headers = wp_get_http_headers('http://wordpress.org');

print_r( $response_headers );

/*
Array
(
	[server] => nginx
	[date] => Wed, 22 Jun 2016 02:03:20 GMT
	[content-type] => application/json
	[content-length] => 316
	[connection] => close
	[access-control-allow-origin] => *
	[access-control-allow-credentials] => true
)
*/

2 и 3 пример, никогда не содержать тело ответа и их использование может пригодится для высоко-нагруженных API, которые ограничивают число запросов в период времени. Так, перед тем как получить тело запроса, нужно проверить: а были ли изменены данные, отвечает ли сервер на наш запрос и т.д. В таких случаях, рекомендуется сначала отправить HEAD запрос, обработать ответ, где проверить есть ли новые данные и только потом делать полный запрос с получением тела ответа.

#5 Получение кода ответа

$response = wp_remote_get('http://httpbin.org/get?a=b&c=d');

echo wp_remote_retrieve_response_code( $response ); //> 200
echo wp_remote_retrieve_response_message( $response ); //> OK

#6 Произвольный тип запроса

Кроме GET и POST типов запросов, мы можем отправлять любой другой, например, PUT или DELETE.

Для этого используем функцию wp_remote_request(), которая лежит в основе всех функций запросов:

$url = 'http://httpbin.org';

$args = array(
	'method' => 'PUT',
	//'method' => 'DELETE'
);

$response = wp_remote_request( $url, $args );

#7 Получение данных о фильме с Конопоиска

Этот пример показывает, как получить данные фильма с Кинопоиска, по указанному ID фильма.

/**
 * Получим информацию о фильме с сайта Kinopoisk
 * Работает на базе сервиса http://docs.kinopoiskapi.apiary.io/.
 *
 * @param int $id ID фильма на сайте
 * @return string|WP_Error Получает тело ответа, в случае успеха и объект WP_Error при неудаче
 */
function kinopoisk_get_movie( $id ) {

	// Параметры GET запроса
	$params = array(
		'filmID' => absint( $id ),
	);

	// Создадим URL с параметрами
	$url = 'http://api.kinopoisk.cf/getFilm';
	$url = add_query_arg( $params, esc_url_raw($url) );

	// запрос
	$response = wp_remote_get( $url );

	// Проверяем код ответа
	$response_code    = wp_remote_retrieve_response_code( $response );
	$response_message = wp_remote_retrieve_response_message( $response );
	$response_body    = json_decode(wp_remote_retrieve_body( $response ));

	if ( 200 != $response_code && ! empty( $response_message ) )
		return new WP_Error( $response_code, $response_message );

	elseif ( 200 != $response_code )
		return new WP_Error( $response_code, 'Неизвестная ошибка' );

	elseif( ! $response_body )
		return new WP_Error( 'nodata', 'Нет данных о фильме или такого фильма нет в базе' );

	else
		return $response_body;
}

// Пример использования функции ---

// Запрос
$res = kinopoisk_get_movie( 714888 );

// Выводим ошибку или информацию
if ( is_wp_error( $res ) )
	echo 'Ошибка при запросе к IMDB: '. wp_strip_all_tags( $res->get_error_message() );

else
	echo 'Фильм: "' . esc_html( $res->nameRU ) .'" ('. (int) $res->year .' год). Рейтинг: '. $res->ratingData->rating;

// в результате получим:
// Фильм: "Звёздные войны: Пробуждение силы" (2015 год). Рейтинг: 7.3

Сохранение результата запроса (кэширование)

Кэшировать результат HTTP запроса нужно всегда, исключений, пожалуй, не бывает.

Очень важным моментом является кэширование результата - сохранение его куда-нибудь. Важно это, потому что без кэша, страницы сайта будут генерироваться медленно. Чтобы осознать всю важность кэширования, нужно понять, как все происходит и почему HTTP запросы будут тормозить загрузку страницы.

Дело в том, что при использовании одной из функций HTTP API наш сервер отправляет запрос на другой сервер и ждет ответа. В период ожидания, никакие PHP операции на нашем сервере не происходят - он просто останавливает выполнение скрипта и ждет. Такое ожидание может быть довольно долгим. Как правило, такое ожидание длится от 0,5 до 5 секунд.

Картина выглядит примерно так: нам на сервер пришел HTTP запрос: http://site.ru/page, и наш сервер должен показать страницу page. Для этого наш сервер начинает генерировать эту страницу, при этом до выполнения каких либо операций по генерации страницы, подключаются различные модули: nginx, apach, PHP, модули PHP и т.д. Затем начинается генерация страницы, и чем сложнее страница, тем дольше она будет генерироваться. Но при этом, сервер использует свои данные из оперативной памяти, с диска, с базы данных и т.д. все эти данные он получает за доли секунды. А теперь представим, что в какой-то момент сбора данных и генерации страницы, нужно получить данные с другого сервера. В этот момент собирается запрос и отправляется, и наш сервер ждет ответа: пока запрос дойдет до другого сервера, пока там соберутся все модули, пока страница (ответ) сгенерируется и пока он вернется к нам через все узлы интернет соединения. Все это по меркам сервера, очень долго - от 0,5 до 5 секунд. А что если таких запросов несколько, например для данных в какой-нибудь таблице?

А теперь, ответе сами себе, нужно ли сохранять данные запроса на свой сервер, где он может получить их за доли секунды?

Другая проблема: «пропускная способность»

Теоретически можно обойтись без кэширования, если у вас на странице всего один HTTP запрос и сервер обрабатывающий этот запрос позволяет отправлять ему неограниченное количество запросов. Но как правило, если вы используете какой-то API, на сервере где обрабатываются запросы, стоит ограничение на количество запросов в промежуток времени, так называемая «пропускная способность» API. И в какой-то момент, удаленный сервер просто не ответит на ваш запрос, а вы не получите нужных данных.

На основе всего вышесказанного можно сделать единственно правильный вывод - кэшировать HTTP запросы нужно всегда, а сделать это совсем не сложно.

Кэширование во временные опции (transients)

Итак мы отправили запрос, получили результат и теперь нам нужно его сохранить. Вариантов куда сохранять результат много. Например, мы можем записать результат в файл и в следующий раз брать его от туда, или можно сохранить результат в базу данных. Но это потребует дополнительного кода, который, как правило не нужен, потому что в WordPress уже есть подходящие функции:

Где:

$transient(строка) (обязательный)
Название временной опции. Максимальная длина 172 знака. Ожидаются данные с экранированными слэшами, очистка слэшей делается автоматически перед записью в БД. Функция автоматически защищает от SQL инъекций.
$value(смешанный) (обязательный)
Значение временной опции. Ожидаются данные с экранированными слэшами, очистка слэшей делается автоматически перед записью в БД. Функция защищает от SQL инъекций. Сериализация, если передается массив, также делается автоматически.
$expiration(строка/массив/число/объект/логический)

Время жизни опции в секундах, начиная с настоящего момента. Например, чтобы записать опцию на один день, нужно указать 60 * 60 * 24.

Если указать 0 - опция никогда не удалиться и не будет иметь срока давности. Получается это будет обычная опция, только с префиксом _transient_ в её названии - это будет означать, что она временная и при чистке таблицы wp_options её можно будет смело удалять, без риска, что-то испортить.
По умолчанию: 0

Важный момент про временные опции (transients). Они умеют работать с объектным кэшированием. Т.е. они записываются на время в базу данных wp_options. Но если на сайте установлен модуль (плагин) объектного кэширования, то они не записываются в БД, а сохраняются в файлы объектного кэша.

#1 Примеры кэширования HTTP запроса во временную опцию

Допустим, через HTTP запрос мы получаем курс рубля со стороннего сайта. Чтобы ускорить загрузку страницы, нам нужно кэшировать полученный результат на 12 часов.

$transient = 'one_usd_in_rub'; // название временной опции

$usd_in_rub = get_transient( $transient ); // пробудем получить сохраненные данные

// если данных нет, или они просрочены, получим и сохраним их
if( ! $usd_in_rub ){
	$url = 'http://www.cbr.ru/scripts/XML_daily.asp';
	$expiration = DAY_IN_SECONDS / 2; // время жизни кэша - пол дня

	$resp = wp_remote_get( $url ); // получим данные

	// если статус ответа 200 - ОК
	if( wp_remote_retrieve_response_code($resp) === 200 ){
		$body = wp_remote_retrieve_body( $resp );

		$xml = simplexml_load_string($body); // парсим XML данные
		$data = json_decode(json_encode($xml)); // превратим в обычный объект

		//print_r( $data );

		$USD = wp_list_filter( $data->Valute, array('CharCode'=>'USD') ); // получим только данные USD
		$USD = array_shift($USD);

		/*
		stdClass Object (
			[NumCode] => 840
			[CharCode] => USD
			[Nominal] => 1
			[Name] => Доллар США
			[Value] => 64,0165
		)
		*/

		// echo "$USD->Nominal $USD->Name равен $USD->Value руб."; //> 1 Доллар США равен 64,0165 руб. 

		$usd_in_rub = $USD->Value;
	}
	// статус ответа не 200 - ОК
	else
		$usd_in_rub = 'нет данных';

	// сохраним курс доллара во временную опцию
	set_transient( $transient, $usd_in_rub, $expiration );
}

echo 'Курс доллара к рублю на сегодня: $1 = '. $usd_in_rub .' руб.';
//> Курс доллара к рублю на сегодня: $1 = 64,0165 руб.

Результатом работы этого кода, будет получение свежего курса доллара каждые пол дня.

Удаление временной опции

Допустим, вы уже не используете временную опцию и она не обновляется, и больше не нужна. В этом случае её лучше удалить. Временная опция сама по себе не удаляется и будет находиться в таблице wp_options до тех пор, пока вы не очистите все временные опции специальным плагином или как-то еще. Поэтому её рекомендуется удалить в ручную, если она уже не используется. Сделать это можно вызвав один раз такую строку:

delete_transient('название_временной_опции');

Кэширование в метаполя

Для кэширования, временные опции подходят всегда, но не всегда это разумно. Для пояснения, представим такую ситуацию: у вас на сайте есть записи, допустим это фильмы и для каждого фильма вы парсите данные с внешнего источника, например, рейтинг Кинопоиска. Такие данные также нужно иногда обновлять, например раз в неделю.

В этом случае, будет логичнее сохранять полученные данные не в таблицу опций, а в метаполя записи. Потому что так их будет удобнее получать, мы получим возможность сортировать записи по рейтингу (по метаполю), к тому же это будет работать быстрее и грамотнее по коду. Потому что при установке параметра $expiration у временных опций, для их получения делается 2 простых запроса к базе данных, тогда как с метаполями WordPress работает гораздо эффективнее.

Но при использовании метаполей, вам нужно вручную проверять время жизни данных и обновлять их при необходимости. Время жизни данных можно записывать в схожее по названию метаполе. Кстати, во временных опциях в таблице wp_options делается тоже самое - создается временная опция и рядом еще одна опция с похожим названием и значением времени, когда опция устаревает.

#1 Примеры кэширования HTTP запроса в метаполя

Для примера, возьмем аналогию, где записи это фильмы и для получения данных фильма с Кинопоиска используется функция kinopoisk_get_movie( $id ) из примера выше. Также, предположим, что для каждой записи у нас уже есть ID фильма на Кинопоиске и находится он в метаполе kinopoisk_id.

Теперь, давайте напишем код для еженедельного обновления рейтинга каждого фильма. Для этого создадим функцию которая выводит рейтинг и одновременно проверяет не нужно ли обновить или получить данные:

function get_film_rating( $post_id = 0 ){
	if( ! $post_id ) $post_id = $GLOBALS['post']->ID;

	$rating  = get_post_meta( $post_id, 'kinopoisk_rating', 1 );
	$up_time = get_post_meta( $post_id, 'kinopoisk_rating_uptime', 1 );

	// проверим нужно ли обновить данные
	if( time() > $up_time + WEEK_IN_SECONDS ){
		// время просрочено или нет данных в метаполях

		$film_id = get_post_meta( $post_id, 'kinopoisk_id', 1 );

		// пробуем получить данные с Кинопоиска
		$res = kinopoisk_get_movie( $film_id );

		// удалось получить данные!
		if( ! is_wp_error($res) && $res->ratingData->rating )
			$rating = $res->ratingData->rating;
		// ошибка при получении данных. Оставим рейтинг какой был или установим -1 (нет рейтинга), если до этого не было рейтинга
		else
			$rating = $rating ?: '-1';

		// обновим метаполя
		update_post_meta( $post_id, 'kinopoisk_rating_uptime', time() );
		update_post_meta( $post_id, 'kinopoisk_rating', $rating );
	}

	return $rating; 
}

// Функция готова, теперь на странице, где нужно вывести рейтинг вызываем её так:
echo get_film_rating();
HTTP API WordPress 7 комментариев
  • campusboy1844 cайт: wp-plus.ru

    Будьте аккуратны при прочтении таких статей, ибо можно неожиданно получить WP-оргазм.

    Небольшие замечания (описки):

    Очень важным моментом является кэширвоание

    Про кеширование особенно было интересно почитать, а использование временных опций вообще супер, это ж эдакая замена Крону.

    Часто пользуюсь http-api, то надо запрос к API Метрике кинуть, то для парсера подтянуть данные в удобном виде, да и проверки удобно проводить. Много применений.

    Отличная шпаргалка. Большое спасибо, Тимур!

    Ответить1.2 года назад #
  • Otshelnik-Fm182 cайт: across-ocean.otshelnik-fm.ru

    Статья отличная. И за новый сервис-транслятор апи кинопоиска спасибо. Не знал о нем. Теперь будет повод потренироваться

    1
    Ответить1.2 года назад #
  • Тимур, не буду оригинальным, но еще раз поблагодарю Вас за созданный сайт, и это большая удача что я его нашел в сети, спасибо, успехов !

    Ответить1.1 года назад #
  • campusboy1844 cайт: wp-plus.ru

    Вышла новая версия WP 4.6, в ней новая библиотека Requests заменяет стандартный HTTP API в WordPress, позволяющая выполнять параллельные запросы и многое другое. Пруф.

    Ответить1.1 года назад #
    • Kama4464

      Судя по тому что там написано. Она в это версии (4.6) пока особо ничего нового не позволяет. И этот релиз направлен на стабильный переход на эту библиотеку. Параллельные запросы возможны пока только, если использовать Requests напрямую.

      Спасибо за коммент, добавил об этом информацию в статью. thank_you

      Ответить1.1 года назад #
  • Рустам cайт: video-prikoli.ru @

    Спасибо, код очень помог брать динамически данные с кинопоиска, извиняюсь, а не подскажете как переделать функцию get_film_rating() что бы брать, кешировать и выводить несколько полей с кинопоиска? Например, дополнительно к рейтингу, актеров, жанр, что бы можно было цеплять постер к фильму, трейлер - если не затруднит, то укажите пожалуйста как переделать функцию get_film_rating()
    п.с. Данные к фильмам получаю через это апи - http://getmovie.cc/api-kinopoisk.html
    Они отдают все нужные поля к кинопоиску
    Заранее огромное спасибо!

    Ответить5 дней назад #

Здравствуйте, !

Ваш комментарий