Capturando los datos remotos de la API meteorológica
El msg
que estás mostrando en tu pregunta es básicamente el resultado de la API meteorológica. Y dice que no hay datos disponibles para su ubicación.
Lo primero que quiere hacer es investigar en el Codex y la "API WP HTTP" .
La forma correcta / WP de capturar datos remotos
Después de que haya aprendido sobre la API HTTP de WP, verá que la forma común de hacerlo es (simplificada de esta manera):
$response = wp_remote_request( 'http://example.com?some=parameter', array(
'ssl_verify' => true
) );
Si hay un error (como se muestra en su ejemplo), podrá detectarlo utilizando la WP_Error
clase:
is_wp_error( $response ) AND printf(
'There was an ERROR in your request.<br />Code: %s<br />Message: %s',
$response->get_error_code(),
$response->get_error_message()
);
Entonces es hora de obtener los datos apropiados. Esto se mostrará 200
y OK
, si todo en el lado remoto funcionó. IMPORTANTE: los datos remotos probablemente no seguirán un estándar que el interno. Por lo tanto, puede haber errores, pero aún recibirá el 200/OK
mensaje positivo de ellos.
$response_code = wp_remote_retrieve_response_code( $response );
$response_status = wp_remote_retrieve_response_message( $response );
Obtén el resultado
Finalmente es hora de inspeccionar el resultado. Primero, nos deshacemos de los espacios en blanco iniciales / finales. En el siguiente ejemplo, verá cómo usar la API HTTP de WP para verificar el encabezado. Si atrapamos JSON
, entonces vamos con json_decode()
y si tenemos XML
, entonces vamos con la SimpleXML
clase nativa de PHP .
// Prepare the data:
$content = trim( wp_remote_retrieve_body( $response ) );
// Convert output to JSON
if ( strstr( wp_remote_retrieve_header( $response, 'content-type' ), 'json' ) )
{
$content = json_decode( $content );
}
// … else, after a double check, we simply go with XML string
elseif ( strstr(
wp_remote_retrieve_header( $response, 'content-type' ),
'application/xhtml+xml'
) )
{
// Lets make sure it is really an XML file
// We also get cases where it's "<?XML" and "<?xml"
if ( '<?xml' !== strtolower( substr( $content, 0, 5 ) ) )
return false;
// Also return stuff wrapped up in <![CDATA[Foo]]>
$content = simplexml_load_string( $content, null, LIBXML_NOCDATA );
}
// If both didn't work out, then we maybe got a CSV, or something else...
En el caso de un archivo CSV, tendrá que encontrar una solución personalizada o buscar una clase PHP en los interwebs. Pero honestamente: si están usando CSV, es más fácil buscar otro servicio.
Caché los datos con un transitorio
La API transitoria ofrece una forma bastante agradable de hacer esto:
// Set Transient
$transient = set_transient(
'Your cache key',
$content,
60*60*6
);
Entonces deberías poder atrapar al transitorio con get_transient()
.
Errores comunes
Un error frecuente es que la verificación SSL no funciona. Con mucho gusto puedes encenderlo / apagarlo bastante fácil:
// ON:
add_filter( 'https_ssl_verify', '__return_true' );
// OFF:
add_filter( 'https_ssl_verify', '__return_false' );
Hay una cosa bastante divertida, como descubrirá cuando inspeccione el archivo core apropiado: Core también tiene un filtro para solicitudes locales . Pero no te dejes engañar por este. ¡Este filtro solo está destinado a usarse en caso de que A) proporcione un servicio remoto desde su instalación WP y B) también lo consuma usted mismo! Lo sé, este puede ser un #WTF?!
momento en el que este no es un cambio para que usted use diferentes configuraciones de verificación SSL entre su instalación local y su entorno / servidor de producción, pero también tiene una idea detrás: es probar los servicios que usted proporcione usted mismo como también le expliqué a la comunidad de WP G + aquí .
// Debug your own service without SSL verification.
add_filter( 'https_local_ssl_verify', '__return_false' );
Depuración de la solicitud y sus resultados
Sin profundizar demasiado en el proceso de actualización, pero la API WP HTTP utiliza la clase WP_HTTP. También ofrece algo agradable: un gancho de depuración.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Donde $response
también puede haber un WP_Error
objeto que quizás te diga más.
Nota: a partir de una breve prueba, este filtro parece funcionar solo (por alguna razón) si lo coloca tan cerca de donde realmente está haciendo la solicitud. Entonces, tal vez deba llamarlo desde una devolución de llamada en uno de los siguientes filtros.
Y NO RIZO?
Fácil. Todo el funkiness de la "API HTTP WP", que he mostrado anteriormente, es básicamente un contenedor basado en funciones para las WP_HTTP
partes internas de la clase, que actúa como clase base (y se extenderá para diferentes escenarios). Los extienden WP_HTTP_*
clases son Fsockopen
, Streams
, Curl
, Proxy
, Cookie
, Encoding
. Si 'http_api_debug'
conecta una devolución de llamada a la acción, el tercer argumento le dirá qué clase se utilizó para su solicitud. No tiene que llamar a las clases directamente. Solo usa las funciones.
Para la mayoría de las solicitudes API remotas / HTTP, es la WP_HTTP_curl
clase, que es un contenedor para la curl
biblioteca nativa de PHP .
Dentro de la WP_HTTP_curl
clase, encontrarás el request()
método. Este método ofrece dos filtros para interceptar el comportamiento SSL: uno para solicitudes locales 'https_local_ssl_verify'
y otro para solicitudes remotas 'https_ssl_verify'
. WP probablemente definirá local
como localhost
y lo que se obtiene return
a partir get_option( 'siteurl' );
.
get_transient()
, pero con la solicitud de la API: como se indica en el mensaje de error. Además de recomendar su usowp_remote_post
, solo tendrá que asegurarse de que la solicitud que se envía sea válida.