web-dev-qa-db-fra.com

wp_headers vs send_headers. Quand utiliser chacun?

J'ai déjà vu wp_headers et send_headers déjà utilisés pour la même chose et je me demande comment vous supposez savoir lequel utiliser et quand ...

Sur la send_headers page codex il y a un exemple d'ajout du X-UA-Compatible: IE=Edge,chrome=1 pour la compatibilité descendante d'Internet Explorer puisque la balise méta souvent échoue sur les sites intranet si chargé trop tard .

Voici à quoi ressemble l'exemple send_headers:

add_action( 'send_headers', 'add_header_xua' );
function add_header_xua() {
    header( 'X-UA-Compatible: IE=Edge,chrome=1' );
}

Cependant wp_headers peut aussi faire ceci:

_ { apply_filters ( 'wp_headers', array $headers, WP $this )

add_filter( 'wp_headers', 'wpieeam_headers' );
function wpieeam_headers($headers) {
    if (!is_admin()) {
        $headers['X-UA-Compatible'] = 'IE=Edge,chrome=1';    
    }
    return $headers;
}

Mise à jour: En fait, je viens de remarquer que une conversation à ce sujet plus ou moins commencé sur une question similaire il y a quelques années ...

En outre, send_headers ne concerne-t-il que le front-end? J'ai vu wp_headers faire des vérifications comme celle-ci:

if ( isset($_SERVER['HTTP_USER_AGENT']) && (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') !== false) )

et

if (!is_admin())

donc je pense que peut-être que send_headers n'a pas à faire ces vérifications ...

filtersactionsheadersbrowser-compatibility
9
Bryan Willis

Ok donc je pense que je l'ai compris ...

Les deux fonctionnent pour la plupart comme vous le souhaiteriez en envoyant des en-têtes http/php au navigateur. wp_headers est en fait un filtre à l'intérieur des fonctions send_headers().Vous pouvez l'utiliser pour modifier les en-têtes avant qu'ils ne soient envoyés au navigateur, à quelques exceptions près. wp_headers ne pourra rien faire s'il s'agit d'une page en cache statique qui traite de ...

C'est ici que le hook send_headers entre en jeu. Après le filtre wp_headers, la fonction send_headers() vérifie si Last-Modified a été envoyée, nous dira si la page a été mise en cache ou non, puis nous permet d’y répondre après que la mise en cache, le type de contenu, etc. aient été envoyés.

Donc, pour mon exemple utilisant X-UA-Compatible, alors qu'ils travaillent tous les deux, je suis enclin à utiliser send_headers. Pourquoi? Si vous deviez ajouter ces deux éléments, send_headers l'emporterait à chaque fois et garantirait son chargement même s'il était ajouté après la mise en cache de la page.

L'utilisation d'une balise <meta> telle que de nombreux frameworks populaires fonctionnerait également pour x-ua-compatible, cela ne fonctionnera pas dans de nombreux navigateurs à moins d'être chargé presque immédiatement après la balise head d'ouverture. Cela est dû à diverses raisons, par exemple si le paramètre "intranet" est défini sur l’ensemble du réseau . Pour cette raison, utiliser la méthode php est plus sûr. Toutefois, si vous deviez ajouter les deux, la balise méta gagnerait (en supposant qu’elle soit incluse suffisamment tôt.

En ce qui concerne la compatibilité avec X-UA-Compatible, j'espère que ce ne sera plus bientôt nécessaire car Microsoft supprime la prise en charge des anciennes versions de IE la semaine prochaine!

De plus, j'ai testé le filtre wp_headers sans utiliser la vérification is_admin() et il ne modifiera pas les admin_headers, de sorte que cette vérification est inutile.

Si vous avez besoin de modifier les en-têtes de l'administrateur pour une raison quelconque, je sais que vous pouvez le faire comme ceci, mais je ne suis pas sûr que cela fonctionnerait tout le temps ...

function admin_add_my_header() {
    header('X-UA-Compatible: IE=Edge,chrome=1');    
}
add_action( 'admin_init', 'admin_add_my_header', 1 );

Réponse mise à jour sur la base de la suggestion de Toscho de vérifier pour admin: 

is_admin() || add_action('send_headers', function(){ 
    header('X-UA-Compatible: IE=Edge,chrome=1'); 
}, 1);
8
Bryan Willis