webleads-tracker

WordPress & Référencement naturel
Mes servicesWordPress - Référencement
Hébergement WordPress
Vous êtes ici : SeoMix » WordPress » Hacks, fonctions et snippets WordPress » Détecter la page d’article dans WordPress

Détecter la page d’article dans WordPress

De base, WordPress dispose de nombreuses fonctions qui permettent de détecter sur quel type de page le visiteur est : page d'accueil, catégorie, article, page, ...

Mais il existe un cas de figure dans lequel une telle fonction n'existe pas: détecter si le contenu actuel est celui qui liste l'ensemble des articles, quand celui-ci est une page.

Pour ceux qui n'ont ni le temps ni l'envie de lire jusqu'au bout cet article, il faut retenir une chose : si vous utilisez la fonction is_home, vous devez impérativement tester également is_front_page pour éviter des incohérences sur certaines configurations.

La problématique

Il est en effet possible dans l'administration de WordPress de paramétrer l'accueil de son site avec le contenu d'une page statique. Lorsque ce paramètre est activé, vous pouvez alors définir une autre page pour lister tous les articles de votre site Internet, grâce à l'option "La page d’accueil affiche une page statique".

Menu lecture et page statique de WordPress

Le menu Lecture permet de définir des pages pour l'accueil et la liste des articles

Cette "page d'article" se comporte comme l'ancien accueil de votre site, mais elle n'est pas toujours détectée en tant que telle. En fait, elle considérée comme étant la page d'accueil avec la fonction is_home (ce qui est illogique car il ne s'agit pas de l'accueil mais d'une page du site) mais elle ne l'est pas avec is_front_page (ce qui est logique car ce n'est pas la racine du site).

if ( is_home() ) {
   //OUI
}
if ( is_front_page() ) {
   //NON
}

Dans ce cas de figure, nous avons donc le fonctionnement suivant :

  • L'accueil du site utilise une page statique du site
    • L'URL est monsite.com
    • is_home = TRUE
    • is_front_page = TRUE
  • La page qui liste tous les articles du site est une page statique du site
    • L'URL est monsite.com/mapage
    • is_home = TRUE
    • is_front_page = FALSE

Deux URL différentes sont donc détectées avec la même fonction : is_home. La problématique est de donc de détecter le second cas de figure, sans interférence avec les autres contenus du sites.

Les solutions

Pour faire cela, j'avoue m'être compliqué énormément la tâche au départ. Je testais si fonction is_home renvoyait vraie, et ensuite je comparais l'URL actuelle avec l'URL renseignée dans les options de WordPress. Cela donnait ce code :

// On vérifie si on est sur une "page d'accueil"
if (is_home()){

    // On teste si l'accueil est une page statique et si une autre page a été définie comme devant afficher une liste d'article
    if( get_option('show_on_front') == 'page') {

      // Quelle est l'URL actuelle ?
      $uri = "http://".$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"];

      // Quelle est l'URL de la page qui doit afficher les articles ?
      $url = get_page_link(get_option('page_for_posts'));  

      // Si elles sont identiques
      if($uri == $url) {
        // Mon code
      }

      //Si elles ne sont pas identiques
      else {
        // Mon code
      }
    }
}

En réalité, il y a beaucoup plus simple pour tester si la page actuelle de WordPress est celle qui liste les articles : l'utilisation conjointe de is_home et is_front_page.

// Si je suis le faux accueil mais pas la page d'accueil...
  if ( is_home() && !is_front_page() ) {
    //Mon code
  }

A quoi cela sert ?

Au départ, j'avais travaillé sur cette fonction pour pouvoir corriger mon fil d’Ariane pour les rares sites configurés de cette manière. Mais en réalité, je me suis rendu compte que ce code WordPress va me servir partout, et vous aussi.

Si vous développez des plugins ou encore si vous modifiez des thèmes WordPress, vous risquez de générer des bugs et incohérences pour les sites configurés ainsi :

  • is_category sera toujours FAUX, alors que le webmaster peut vouloir un affichage identique à celui des catégories pour la page qui liste tous les articles du site.
  • is_home sera VRAI même quand vous n'êtes pas sur la page d'accueil du site (en l’occurrence, quand vous serez dans la page qui liste les articles). Il est donc probable que vous allez afficher des éléments incohérents à certains endroits.

En résumé, si vous utilisez la fonction is_home, vous devez impérativement tester également is_front_page pour ne pas avoir d'incohérence entre la page d'accueil du site et la page qui liste les articles. En fonction du cas de figure, voici différentes solution.

Ma page d'articles aura la même mise en page que l'accueil :

if ( is_front_page()||is_home()){
    // Affichage de l'accueil du site et de la page d'article (si elle est définie dans l'administration de WordPress)
} else {
    // Le reste de vos conditions et affichages
}

Ma page d'articles aura la même mise en page qu'une catégorie :

if ( is_front_page()){
    // Affichage de l'accueil réel du site, quel que soit le paramétrage de WordPress
} elseif ( is_home()||is_category()){
    // Affichage de la page qui liste les articles et/ou des catégories
} else {
    // Le reste de vos conditions et affichages
}

Ma page d'articles aura une mise en page différente de l'accueil et des catégories :

if ( is_front_page()){
    // Affichage de l'accueil réel du site, quel que soit le paramétrage de WordPress.

} elseif ( is_home()){
    // Affichage de la page qui liste les articles, si défini dans le paramétrage de WordPress.

} elseif ( is_category()){
    // Affichage des catégories.

} else {
    // Le reste de vos conditions et affichages.
}

Bon codage à tous ;)

Les thèmes relatifs

Voici les thématiques abordées par Détecter la page d’article dans WordPress:

  • Conditionnal Tags -
  • Structure de WordPress
11 commentaires
  1. Julio Potier (BoiteAWeb)
    53 messages

    Julio Potier (BoiteAWeb) - Le 06 décembre 2012, 09:50

    Hello
    J’aime bien ce genre de post, on sent la recherche profonde, la recherche d’une détection d’un comportement, une question à se poser si c’est un bug ou pas etc
    Merci pour l’info donc, c’est très utile et le code est parfait et simple.

  2. Raherian
    2 messages

    Raherian - Le 06 décembre 2012, 14:57

    Hello,
    Je ne trouve pas de problème par rapport à ces fonctions, en étant sur le template home.php en faisant is_home() et is_front_page() j’ai true/false et sur front_page.php j’ai bien false/true. Le comportement est bien celui attendu, je ne sais pas si j’ai mal lu mais ça me parait fonctionner correctement ^^

  3. Daniel Roch
    726 messages

    Daniel Roch - Le 06 décembre 2012, 15:48

    @Raherian : c’est uniquement dans le cas où l’on définit une page statique pour la homepage et une autre page statique pour afficher tous les articles (en lieu et place de la home). Dans le reste des cas de figure, le comportement est normal.

  4. Aurélien Denis
    15 messages

    Aurélien Denis - Le 07 décembre 2012, 18:17

    C’est drôle mais j’ai lu une première l’article sans réellement comprendre le problème… aujourd’hui j’ai été confronté à cette situation : utilisation classique consistant à définir une page d’accueil et une page d’article.

    Et bien, je pense être dans le cas de figure que tu évoques : ma page d’article utilise le fichier index.php et pas le modèle de page associé à la dite page d’article.

    Je ne sais pas si c’est moi qui bug ou pas mais y a certainement quelque chose de louche là dedans.

  5. Julien Maury
    3 messages

    Julien Maury - Le 10 décembre 2012, 09:38

    Salut,

    Donc en fait is_front_page() teste les réglages de lecture (derniers articles, page statique) pour savoir si la valeur de la page en cours correspond ?

    Plus puissant qu’un is_page_template().

  6. MarieEve
    4 messages

    MarieEve - Le 14 décembre 2012, 16:39

    ouh là, c’est bien compliqué tous tes tests!

    Sais-tu qu’il existe un diagramme te permettant de connaitre quel template est utilisé en fonction de ta config (accueil type « static page » ou « blog page », custom-post-type, présence ou non de certains templates facultatifs…) ?

    Ca s’appelle la hiérarchie des templates, voici le lien vers le codex:

    https://codex.wordpress.org/fr:Hi%C3%A9rarchie_des_fichiers_mod%C3%A8les

    Depuis que je l’utilise, je n’ai jamais de surprise sur les templates employés sur telle ou telle page (à moins que le thème n’ait été fait n’importe comment).

  7. Daniel Roch
    726 messages

    Daniel Roch - Le 15 décembre 2012, 10:23

    @MarieEve : je connaissais déjà cette hiérarchie des templates. Le problème, c’est qu’elle est illogique pour la page des articles quand celle-ci a été définie comme étant statique dans l’administration de WordPress.

    Un développeur (de thème ou plugin) peut vouloir faire une mise en page pour l’accueil. S’il utilise la fonction is_home sans is_front_page, il appliquera cette même mise en page à la page des articles, alors qu’elle ne correspond plus à l’accueil du site. On peut donc se retrouver avec un problème majeure d’ergonomie et de structure du site en affichant les mauvais éléments sur la mauvaise page.

  8. Kevin
    1 message

    Kevin - Le 20 décembre 2012, 05:46

    Bonjour,
    Je me suis aperçu que mon site présentait involontairement ce phénomène : une page d’accueil statique qui fonctionne, et une page d’articles (sans filtre de catégorie)… qui me renvoie sur ma page d’accueil :-(
    Ravi de voir que qqn a traité ce sujet :-), mais étant donné mes compétences en codage…
    Le code permet-il de corriger ce bug où de prévenir des plug-ins de cette configuration ?
    Et où insère-t-on ce code ? Dans fonction.php et on fait ensuite appelle à cette fonction dans home.php ? ou dans index.php ? Bref paumé sur ce point.
    Help, plz.

  9. Daniel Roch
    726 messages

    Daniel Roch - Le 22 décembre 2012, 18:08

    Le code permet effectivement de corriger ce bug, mais il ne se place pas n’importe où. Il faut l’adapter pour corriger chaque thème ou plugin qui pose problème.

  10. MarieEve
    4 messages

    MarieEve - Le 27 décembre 2012, 22:33

    Bonjour,
    @Daniel Roch: en effet je comprends ce que tu veux dire. Je n’y avais pas pensé.

    En tout cas merci pour ces explications, je comprends maintenant pourquoi certains plugins censés fonctionner sur la home, ne fonctionnent que si la home est « de type blog » et non « de type page statique ». Le développeur a sûrement oublié un petit « is_front_page » ;)

    A+
    PS: je trouvais assez improbable que tu ne connaisses pas la hiérarchie des templates. oO

  11. titou
    1 message

    titou - Le 13 juillet 2013, 20:37

    Ou ça!

    if( ( get_option('page_for_posts') == $post->ID ) || is_home() ){
    <i>your code</i>
    }
» Commentez cet article !
(Merci de donner un vrai prénom)
(Ne sera jamais publié)
(Modèration subjective)
Html accepté <a> <i> <b> [codesyntax]CODE[/codesyntax]
» Prévisualisez votre message

© 2010-2012 SeoMix : WordPress & Référencement
Propulsé par WordPress et Daniel Roch. Logo créé par Willy-Bahuaud

Indispensable
WordPress
A propos de SeoMix
Mes servicesWordPress - Référencement
Suivez-nous !
  • 8855 abonnés
  • 197 articles
  • 4614 messages
Vous devriez lire
Seo et emarketing
Les amis
cf7b33c33c76cff834c0b2ea359f1280vvvvvvvvvvvvvvvvv