wp_headers vs send_headers. Quand utiliser chacun?

J'ai déjà vu wp_headerset send_headersutilisé les deux pour la même chose et je me demande comment vous supposez savoir lequel utiliser et quand ...

Sur la send_headerspage du codex, il existe un exemple d'ajout de la X-UA-Compatible: IE=edge,chrome=1compatibilité descendante pour Internet Explorer, car la balise meta échoue souvent sur les sites intranet si elle est chargée trop tard .

Voici à quoi send_headersressemble l' exemple:

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

Cependant, vous wp_headerspouvez également le faire:

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: je viens de remarquer qu'une conversation à ce sujet a plus ou moins commencé sur une question similaire il y a quelques années ...

En outre, send_headers n'a-t-il à voir qu'avec le frontal? J'ai vu wp_headers faire des vérifications comme ceci:

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

et

if (!is_admin()) 

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

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

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

C'est là que le send_headerscrochet entre en jeu. Après le wp_headersfiltre, la send_headers()fonction vérifie si Last-Modifieda été envoyée avec nous indiquerait si la page a été mise en cache ou non et nous permet ensuite de nous y connecter après que la mise en cache, le type de contenu, etc. ont tous été envoyés.

Donc, pour mon exemple d'utilisation X-UA-Compatible, alors qu'ils fonctionnent tous les deux, je suis enclin à utiliser send_headers. Pourquoi? D'une part, si vous deviez ajouter les deux, send_headerscela gagnerait à chaque fois et garantirait qu'il était chargé même s'il était ajouté après la mise en cache de la page.

Bien que l'utilisation d'une <meta>balise comme de nombreux frameworks populaires fonctionne également pour X-ua, elle ne fonctionnera pas dans de nombreux navigateurs à moins d'être chargée presque immédiatement après la balise head d'ouverture. Cela est dû à diverses raisons, comme si le paramètre "intranet" est défini sur l'ensemble du réseau . Pour cette raison, l'utilisation de la méthode php est plus sûre. Cependant, si vous ajoutiez les deux, la balise META gagnerait (en supposant qu'elle soit incluse suffisamment tôt.

En ce qui concerne la X-UA-Compatiblecompatibilité, j'espère que cela ne sera bientôt plus pertinent puisque Microsoft abandonne la prise en charge des anciennes versions d'IE la semaine prochaine!

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

Si vous aviez besoin de modifier les en-têtes d'administrateur pour une raison quelconque, je sais que vous pouvez le faire comme ça, mais je ne sais pas si 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 basée sur la suggestion de Toscho de vérifier pour l'administrateur:

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