Capture des données distantes de l'API météo
Le msg
, que vous montrez dans votre question est essentiellement le résultat de l'API météo. Et il est dit qu'aucune donnée n'est disponible pour votre emplacement.
La première chose que vous voulez faire est une recherche dans le Codex et la "WP HTTP API" .
La bonne façon / WP pour saisir des données à distance
Après avoir découvert l'API HTTP WP, vous verrez que la façon la plus courante de le faire est (simplifiée comme ceci):
$response = wp_remote_request( 'http://example.com?some=parameter', array(
'ssl_verify' => true
) );
S'il y a une erreur (comme indiqué dans votre exemple), vous pourrez l'attraper en utilisant 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()
);
Il est alors temps d'obtenir les données appropriées. Cela montrera 200
et OK
, si tout sur le côté distant a fonctionné. IMPORTANT: Les données distantes ne suivront probablement aucune norme que leur interne. Il peut donc y avoir des erreurs, mais vous obtiendrez toujours le 200/OK
message positif de leur part.
$response_code = wp_remote_retrieve_response_code( $response );
$response_status = wp_remote_retrieve_response_message( $response );
Obtenez le résultat
Enfin, il est temps d'inspecter le résultat. Tout d'abord, nous nous débarrassons des espaces blancs avant / arrière. Dans l'exemple suivant, vous voyez comment utiliser l'API HTTP WP pour vérifier l'en-tête. Si nous avons attrapé JSON
, alors nous allons avec json_decode()
et si nous avons XML
, alors nous allons avec la SimpleXML
classe native 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...
Dans le cas d'un fichier CSV, vous devrez trouver une solution personnalisée ou rechercher une classe PHP sur les interwebs. Mais honnêtement: s'ils utilisent CSV, il est plus facile de rechercher un autre service.
Cachez les données avec un transitoire
L' API transitoire offre une assez belle façon de procéder:
// Set Transient
$transient = set_transient(
'Your cache key',
$content,
60*60*6
);
Vous devriez alors pouvoir attraper le transitoire avec get_transient()
.
Erreurs courantes
Une erreur souvent rencontrée est que la vérification SSL ne fonctionne pas. Heureusement, vous pouvez l'activer / le désactiver assez facilement:
// ON:
add_filter( 'https_ssl_verify', '__return_true' );
// OFF:
add_filter( 'https_ssl_verify', '__return_false' );
Il y a une chose assez drôle, comme vous le découvrirez en inspectant le fichier core approprié: Core a également un filtre pour les requêtes locales . Mais ne vous laissez pas berner par celui-ci. Ce filtre est uniquement destiné à être utilisé dans le cas où vous A) fournissez un service à distance depuis votre installation WP et B) le consommez vous-même! Je sais, cela peut être un bon #WTF?!
moment que ce n'est pas un commutateur pour que vous utilisiez différents paramètres de vérification SSL entre votre installation locale et votre environnement / serveur de production, mais il a également une idée derrière: c'est pour tester les services que vous fournissez-vous comme je l'ai également expliqué à la communauté WP G + ici .
// Debug your own service without SSL verification.
add_filter( 'https_local_ssl_verify', '__return_false' );
Débogage de la requête et de ses résultats
Sans creuser trop profondément dans le processus de mise à jour, mais l'API HTTP WP utilise la classe WP_HTTP. Il offre également une bonne chose: un crochet de débogage.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Où $response
peut aussi être un WP_Error
objet qui vous en dit peut-être plus.
Remarque: à partir d'un bref test, ce filtre semble ne fonctionner (pour une raison quelconque) que si vous le placez aussi près de l'endroit où vous effectuez réellement la demande. Alors peut-être que vous devez l'appeler à partir d'un rappel sur l'un des filtres ci-dessous.
OUI NON CURL?
Facile. Tout le côté génial de l '"API HTTP WP", que j'ai montré ci-dessus, est essentiellement un wrapper basé sur les fonctions pour les WP_HTTP
internes de classe, qui agit comme classe de base (et sera étendu pour différents scénarios). Les étendant les WP_HTTP_*
classes sont Fsockopen
, Streams
, Curl
, Proxy
, Cookie
, Encoding
. Si vous accrochez un rappel à l' 'http_api_debug'
action, le troisième argument vous indiquera quelle classe a été utilisée pour votre demande. Vous n'avez pas besoin d'appeler directement les classes. Utilisez simplement les fonctions.
Pour la plupart des demandes d'API HTTP / distantes, c'est la WP_HTTP_curl
classe, qui est un wrapper pour la curl
bibliothèque native PHP .
À l'intérieur de la WP_HTTP_curl
classe, vous trouverez la request()
méthode. Cette méthode propose deux filtres pour intercepter le comportement SSL: un pour les requêtes locales 'https_local_ssl_verify'
et un pour les requêtes distantes 'https_ssl_verify'
. WP définira probablement local
aussi localhost
et ce que vous obtenez dans return
de get_option( 'siteurl' );
.
get_transient()
- mais à la demande d'API: comme indiqué par le message d'erreur. En plus de vous recommander d'utiliser,wp_remote_post
vous devrez simplement vous assurer que la demande envoyée est valide.