Cattura dei dati remoti dell'API meteo
Il msg
, che stai mostrando nella tua domanda è fondamentalmente il risultato dell'API meteo. E dice che non ci sono dati disponibili per la tua posizione.
La prima cosa che vuoi fare è una ricerca nel Codex e nella "API HTTP WP" .
Il modo giusto / WP per acquisire dati remoti
Dopo aver appreso dell'API HTTP WP, vedrai che il modo comune per farlo è (semplificato in questo modo):
$response = wp_remote_request( 'http://example.com?some=parameter', array(
'ssl_verify' => true
) );
Se c'è un errore (come mostrato nel tuo esempio), allora sarai in grado di prenderlo usando la WP_Error
classe:
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()
);
Quindi è il momento di ottenere i dati appropriati. Questo mostrerà 200
e OK
, se tutto sul lato remoto ha funzionato. IMPORTANTE: i dati remoti probabilmente non seguiranno uno standard rispetto a quelli interni. Quindi ci possono essere errori, ma riceverai comunque il 200/OK
messaggio positivo da loro.
$response_code = wp_remote_retrieve_response_code( $response );
$response_status = wp_remote_retrieve_response_message( $response );
Ottieni il risultato
Finalmente è il momento di ispezionare il risultato. Innanzitutto, ci sbarazziamo degli spazi bianchi iniziali / finali. Nel seguente esempio, viene illustrato come utilizzare l'API HTTP WP per controllare l'intestazione. Se prendiamo JSON
, quindi andiamo con json_decode()
e se abbiamo XML
, andiamo con la SimpleXML
classe nativa di 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...
Nel caso di un file CSV, dovrai trovare una soluzione personalizzata o cercare una classe PHP negli interwebs. Ma onestamente: se stanno usando CSV, è più facile cercare un altro servizio.
Memorizza nella cache i dati con un Transitorio
L' API Transient offre un modo abbastanza carino per farlo:
// Set Transient
$transient = set_transient(
'Your cache key',
$content,
60*60*6
);
Dovresti quindi essere in grado di catturare il transitorio con get_transient()
.
Errori comuni
Un errore spesso riscontrato è che la verifica SSL non funziona. Volentieri puoi accenderlo / spegnerlo abbastanza facilmente:
// ON:
add_filter( 'https_ssl_verify', '__return_true' );
// OFF:
add_filter( 'https_ssl_verify', '__return_false' );
C'è una cosa piuttosto divertente, come scoprirai controllando il file core appropriato: Core ha anche un filtro per le richieste locali . Ma non lasciarti ingannare da questo. Questo filtro ha lo scopo di abituarsi solo nel caso in cui A) fornisca un servizio remoto all'interno dell'installazione WP e B) lo consumi anche tu! Lo so, questo può essere un bel #WTF?!
momento in cui questo non è uno switch per utilizzare diverse impostazioni di verifica SSL tra l'installazione locale e l'ambiente / server di produzione, ma ha anche un'idea alla base: è testare i servizi che fornisci te stesso come ho spiegato anche alla community di WP G + qui .
// Debug your own service without SSL verification.
add_filter( 'https_local_ssl_verify', '__return_false' );
Debug della richiesta e dei suoi risultati
Senza approfondire troppo il processo di aggiornamento, ma l'API HTTP WP utilizza la classe WP_HTTP. Offre anche una bella cosa: un hook di debug.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Dove $response
può anche essere un WP_Error
oggetto che forse ti dice di più.
Nota: da un breve test, questo filtro sembra funzionare (per qualche motivo) solo se lo posizioni il più vicino possibile al punto in cui stai effettivamente facendo la richiesta. Quindi forse è necessario chiamarlo dall'interno di una richiamata su uno dei filtri di seguito.
Y NO CURL?
Facile. Tutta la stranezza dell '"API HTTP WP", che ho mostrato sopra, è fondamentalmente un wrapper basato sulle funzioni per gli WP_HTTP
interni di classe, che funge da classe di base (e verrà esteso per diversi scenari). Estendentisi WP_HTTP_*
classi sono Fsockopen
, Streams
, Curl
, Proxy
, Cookie
, Encoding
. Se si aggancia un callback 'http_api_debug'
all'azione, il terzo argomento ti dirà quale classe è stata utilizzata per la tua richiesta. Non devi chiamare direttamente le lezioni. Basta usare le funzioni.
Per la maggior parte delle richieste API HTTP / remote, è la WP_HTTP_curl
classe, che è un wrapper per la curl
libreria nativa di PHP .
All'interno della WP_HTTP_curl
classe troverai il request()
metodo. Questo metodo offre due filtri per intercettare il comportamento SSL: uno per le richieste locali 'https_local_ssl_verify'
e uno per le richieste remote 'https_ssl_verify'
. WP probabilmente definire local
come localhost
e cosa si ottiene in return
da get_option( 'siteurl' );
.
get_transient()
- ma con la richiesta API: come indicato dal messaggio di errore. Oltre a consigliarti di utilizzare,wp_remote_post
devi solo assicurarti che la richiesta inviata sia valida.