J'ai un problème assez fondamental pour lequel je suis surpris WP n'a pas de solution native (sauf si j'oublie quelque chose, espérons-le).
J'ai un site WP avec static page
défini comme page de couverture dans le paramètre de lecture. Dans un code de plugin, j'essaie de déterminer si WP affiche la page de couverture et ajoute une classe au tableau $classes
si c'est le cas. J'utilise le code suivant pour l'accomplir
add_filter('body_class', function($classes){
if(is_front_page() || is_home()){
$classes[] = 'home-page';
}
return $classes;
});
J'utilise à la fois is_front_page()
et is_home()
au cas où le paramètre de la page d'accueil changerait de la page statique à la présentation du blog à l'avenir.
Le problème que je rencontre est que ce code ajoute la classe home-page
à body
même sur la page wp-signup.php
.
L'inspection du code révèle que is_front_page()
appelle WP_Query::is_front_page()
, ce qui renvoie essentiellement les résultats de WP_Query::is_page(get_option('page_on_front'))
. Donc, la racine du problème est que wp-signup.php
est considéré comme la page (id) renvoyée par get_option('page_on_front')
( qui renvoie ID
de la page statique définie comme page de couverture dans les paramètres> reading ).
WP_Query::is_page()
utilise WP_Query::get_queried_object()
en interne pour décider si la page en cours est la page présente dans les arguments de la méthode. En wp-signup.php
, le code qui définit l'objet interrogé actuel est le suivant
/*...other code... */
elseif ( $this->is_singular && ! empty( $this->post ) ) {
$this->queried_object = $this->post;
$this->queried_object_id = (int) $this->post->ID;
}
/*...other code... */
Cela montre que wordpress, pour une raison quelconque, interroge la page d'accueil afin d'afficher wp-signup.php
et pose les questions suivantes.
is_front_page()
renvoie des résultats erronés?wp-signup.php
ne peut jamais être défini comme page d’accueil à l’aide des paramètres d’administrateur de Wordpress, alors pourquoi le code wordpress n’expédie-t-il pas en cochant simplement PHP_SELF
ou REQUEST_URI
?$this->post
à ce stade?J'ai exclu problème de plugin en supprimant le répertoire plugins (et mu-plugins). wp-signup.php
est toujours considéré comme une page de couverture alors que ce n'est le cas pour aucune autre page.
Toute aide concernant ce problème sera grandement appréciée.
Mettre à jour
J'utilise WP version 4.2.4 et il s’agit d’une configuration multisite.
Merci.
Juste des spéculations, mais je me demande si vous rencontrez un problème de fonction anonyme. Les fonctions anonymes sont autorisées dans WP et fonctionnent normalement (en supposant que PHP soit mis à jour), mais si vous effectuez une recherche, vous trouverez des rapports sur des bogues suspects ou au moins sur des comportements inattendus.
D'ailleurs, je ne suis pas sûr d'avoir jamais vu une fonction anonyme utilisée à titre d'exemple dans le codex WordPress, et je ne me souviens pas d'avoir jamais rencontré une telle fonction auparavant dans le code de thème et de plug-in. Bien sûr, je n’ai pas cherché d’autres fonctions, mais je pense néanmoins que la fonction ci-dessus sera presque toujours écrite dans une version du format en deux parties plus familier - c’est-à-dire:
add_filter('body_class', 'ejay_add_home_class');
function ejay_add_home_class($classes) {
if (is_front_page() || is_home()) {
$classes[] = 'home-page';
}
return $classes;
}
Donc, à titre expérimental, j'essaierais le format ci-dessus plus "conventionnel", et également avec une priorité supérieure ou inférieure à 10. Si vous associez plusieurs fonctions anonymes au même filtre, je leur attribue des priorités différentes. ou utilisez un tableau (exemple ici: http://snippets.khromov.se/adding-multiple-actions-and-filters-using-anonymous-functions-in-wordpress/ ), ou écrivez chacun d'entre eux comme nommés deux parties, aussi.
En vérité, je trouve le chemin en deux parties légèrement plus long, plus facile à lire, à suivre et à ajuster de toute façon.