Francis Chouquet Graphiste Lettering

Faut-il coder en dur la navigation sur WordPress ?

0

Hier soir, je lisais un article d’Elliot Jay Stocks qui pense que le tout dynamique ne sert à rien et qu’il est souvent préférable de coder directement son menu de navigation en dur dans le fichier adéquat plutôt que d’utiliser les tags WordPress pour avoir un menu dynamique.

article-hardcodenav

J’avoue avoir été surpris par ce billet, mais également par la plupart des commentaires qui l’accompagne, qui vont quasiment tous dans le même sens. Visiblement, beaucoup de personnes trouvent que les tags WordPress pour créer un menu dynamique sont complexes et ne permettent pas parfois d’arriver au résultat escompté. Je dis que j’avoue avoir été surpris parce que, personnellement, que ce soit pour un blog personnel ou pour un client, j’ai toujours tout codé pour que la navigation soit dynamique et je n’ai jamais eu aucun problème.

C’est vrai que parfois ça peut être quelque peu compliqué quand on veut choisir les pages ou catégories à afficher. Elliot, bien qu’étant « pour » un codage en dur, n’oublie pas de mentionner aussi que pour les projets clients ou pour la réalisation de thèmes « publics », il est quand même préférable d’avoir un menu dynamique, mais que pour un projet personnel, il vaux mieux garder les choses simples et coder en dur permet souvent de gagner du temps.

Parmi les commentaires, nombreux sont ceux à penser que les CMS tendent à pousser tout le monde à vouloir faire du tout dynamique. D’ailleurs, il est parfois intéressant de voir les personnes qui veulent un CMS alors que leur contenu n’en nécessite pas un.

Alors, faut-il coder la navigation en dur ? Dans le même genre, faut-il pousser tout ça vers d’autres aspects du CMS ? Je me suis demandé en lisant ce billet si tout ça ne viendrait pas particulièrement de la famille des web designers qui ne veulent pas passer des heures à trouver le bon « snippet », alors que pour un développeur, cette recherche serait toute naturelle.

En tout cas, ce billet a eu le don de me poser la question à moi-même et j’en profite d’ailleurs pour vous la poser: Fait-il coder plus en dur ou alors militer pour le tout dynamique ?

42 Commentaires

  • Hello,

    lorsque tu parles de menu dynamique, tu penses à un menu contextuel? qui dépend de la catégorie (par ex) d’un billet?

  • Thanh > Juste du menu classique où tu utilises wp_list_pages ou wp_list_categories qui est dynamique dans le sens que quand tu modifies une catégorie ou une page dans l’admin, elle est mise à jour directement sur le site ! 😉 Je me suis peut-être mal exprimé !! :-/

  • Ah ben je code en dur 🙂

    Par contre je suis sûr que wp_list_pages peut assurer complètement les fonctionnalités qu’on place dans un menu.

    Je ne me rappelle plus pourquoi pour sutekidane et tranches de vie j’y suis allé de mon code en dur ^^

  • Tout dépend des projets bien entendu. Pour ma part je ne suis pas très fan des menus dynamiques. Cependant cela peut s’avérer utile pour le client.
    La question est plutôt est-ce qu’il y a un besoin à faire des menus dynamiques? Le client aura tendance à ajouter des catégories sans penser au front. Il se rendra compte alors que dans certains cas, visuelement ça ne passe pas.
    Exemple sur le site des 2 Alpes http://www.les2alpes.com/, sur Firefox 3.5 (Mac) le menu passe sous le choix des langues…
    Dans le cas de ce projet, pourquoi un menu dynamique en sachant que la navigation ce fera toujours de la même façon (le menu est le même depuis plus de 2 ans)?
    Donc je suis plus pour le dur.
    Quand pensez-vous?

  • Frédéric,

    effectivement, moi je pensais surtout aux limitations techniques. Mais les contraintes visuelles sont également à prendre en compte.

  • J’avoue que je ne me suis jamais vraiment posé la question: peut etre au départ lorsque je ne connaissais pas vraiment WordPress, mais mettre en place une navigation dynamique est tout de meme relativement simple une fois qu’on a pris la peine de faire un peu de lecture, et d’apprendre a connaitre les différents arguments des fonctions.

    Ensuite, créer un menu de navigation devient quand meme tres simple et tres rapide : je ne me prends pas vraiment la tete avec ca lorsque je bosse avec WordPress, il y a d’autres choses bien plus compliquées qui me bloquent ! 🙂 La navigation devient rapide a créer, aussi rapide que d’hard-coder la chose, et moins embetant quand je réalise qu’il me faut rajouter une page, ou une catégorie…

    Enfin, chacun ses gouts ! 🙂

  • SI l’on est dans un projet impliquant un client, autant laisser en dynamique, comme ça il aura le loisir de changer sa navigation comme bon lui semble via l’admin.

    Par contre pour du perso, ou alors lorsque l’on s’adresse à quelqu’un d’un peu plus tech., autant passer en dur, et ne faire ressortir que ce que l’on veut. Ainsi, on gagne un (petit) peu en ressources, surtout si il y a pas mal de trafic à prévoir.

    Et puis, combien de fois par an une navigation change ? 😉

  • Cela ne me pose pas franchement de problème que les thèmes utilisent des fonctions car généralement ils sont faits pour être rendus publics, et pour un CMS, changer la navigation est quelque chose qui doit être facile et simple pour un non-initié.
    Cependant, je limiterais tous ces appels à fonction à la navigation et coderais en dur tous les liens vers les feuilles de style et les scripts par exemple, ou encore quelques liens en footer vers des catégories choisies etc…
    Donc navigation en dur, non, mais le reste oui 😉

  • Frédéric > Comme Thanh, je n’avais pas pensé aux soucis visuels que ça peut entraîner pour un client s’il rajoute une catégorie ou une page par exemple, et c’est sûr que dans pas mal de cas, ça va tout casser !! 😛 Faudrait peut-être que j’y pense pour certains clients… Mais le souci c’est que généralement, ils veulent du WordPress pour avoir l’impression de pouvoir tout maîtriser, même si c’est vrai que les menus changent TRES rarement !! 😉

  • Ah j’avais lu un article qui disait l’inverse, faut que je le retrouve.

  • J’ajoute que moins il y a de requetes php sur un page, plus elle s’affiche vite. Donc si on peut s’épargner des requetes php pour afficher un simple menu, autant le faire.
    Dans le même sens, je préconise de coder en dur tout les liens vers les images du design, la feuille de style etc.
    Ce n’est ni un choix de developpeur, ni un choix de webdesigner, mais un choix d’utilisateur pragmatique à mon sens.

  • je dirais définitivement en dur, meilleur contrôle de la navigation, meilleur séparation des contenus…après tout dépend de l’utilisation. je sais que j’ai rarement utilisé les template tags de WP pour créer les menus des différents sites que j’ai été amené à faire.

    Pour un thème public, il vaut mieux rester sur le système classique de wordpress … on n’a pas tous envie d’envoyer les mains dans le code.

    Et bien entendu cela depend de la maniere de coder son menu ( Valid XHTML et SEO friendly si possible 🙂 )

  • J’aime bien une solution intermédiaire : utiliser les déclarations de constantes dans le fichier wp-config.php.

    define(‘WP_HOME’, ‘http://maquette….fr/bnpa’);
    define(‘WP_SITEURL’, ‘http://maquette…fr/bnpa’);
    define(‘TEMPLATEURL’, ‘http://maquette….fr/bnpa/wp-content/themes/bnpa’);
    define(‘TEMPLATEPATH’, ‘D:/bnpa/wp-content/themes/bnpa’);
    define(‘STYLESHEETPATH’, ‘D:/bnpa/wp-content/themes/bnpa’);

    Et les réutiliser ensuite pour déclarer css, liens, images, menus…
    Cela réduit très efficacement les appels à bloginfo() et garde une agréable souplesse.

  • Pareil perso je code toujours tout en dur, aussi bien les pages que la liste des catégories, ça permet de mettre certains trucs en gras pour attirer un peu plus l’attention sur certaines catégories « du moment » sans trop se prendre la tête 🙂

  • Damien Caselli

    Le problème avec une navigation dynamique c’est que souvent le design ne permet
    pas de rajouter beaucoup de choses, surtout dans le cas d’une navigation horizontale.

    Pour une navigation verticale placée indépendamment du contenu ça passe, même si ça
    devient kilométrique.

    Si on privilégie l’aspect esthétique, le tout dynamique peut donner des – mauvaises – surprises dans certains cas s’il y a trop de menus à afficher.

    C’est souvent un problème auquel on ne pense qu’après la conception graphique et ça entraine une calvitie précoce chez pas mal de développeurs/intégrateurs.

    Il y a bien une solution 50/50, qui vise à ne laisser qu’un nombre déterminé d’éléments en laissant l’affichage du texte dynamique mais les liens en dur (« finalement je veux renommer cette rubrique »).

    Pour le problème de rapidité d’affichage dû aux requêtes, on peut toujours créer un cache de la navigation, à moins qu’elle change 200x par jour…

  • Pour ma part tout dépend du destinataire du projet. Le tout dynamique à ses avantages pour données la main à des clients qui n’auront plus que le rôle d’administrateur. En termes de graphisme et d’ergonomies et même parfois de services, je m’autorise quelques travers et j’injecte en dur pas mal de choses. 9a permet parfois d’effacer le côté un peu stéréotypé des blogs.

    On a parfois quelques belles surprises avec l’HTML et les CSS.
    Bonne continuation
    w

  • Mmm, je pense qu’il y a effectivement deux écoles, d’un côté les développeurs et de l’autre les designers. Ce qui complique la tâche pour les deux camps c’est que WordPress nécessite une double compétence du fait de son caractère pluridisciplinaire malgré le fait qu’il ne s’agisse pas d’un cms foncièrement compliqué. Il permet de développer des sites administrables tout en conservant des habitudes de création ou d’intégration plutôt classiques. Du coup, il intéresse un peu tout le monde. Les designers voudront naturellement se simplifier la tâche en appliquant des techniques moins dynamiques et les développeurs ne pourront pas imaginer livrer un site sans que toutes les parties du thème ne puissent communiquer avec le module d’administration. Néanmoins la création d’un site est le fruit d’une réflexion menée conjointement avec le client et d’une décision finale qu’on imagine collégiale. Lorsque vous décidez de créer un site sous WordPress pour un client je ne pense pas que vous lui vendiez un « Thème » mais un site administrable personnalisé avec sa charte graphique ce qui fait toute la différence à mon humble avis. La création d’un thème présenté en tant que tel implique bien souvent une grande souplesse d’utilisation car il s’agit avant tout d’un habillage. On s’attend donc qu’il s’adapte à pratiquement n’importe quel site développé sous WordPress.

  • Si le site est pour un client, il préfèrera avoir la main sur un maximum de choses, d’où l’utilisation d’un menu dynamique. D’ailleurs la fonction wp_list_pages est suffisamment bien fichue : on peut paramétrer précisément les pages à afficher, ce qui permet de cadrer correctement l’affichage tout en laissant la possibilité au client de renommer ses pages.

    Pour une utilisation personnelle, coder le menu en dur permet de faire des tests sans influer sur le rendu front…

    Après, effectivement, il y a les questions de performance. Bon, à ce moment là, autant laisser tomber le CMS et faire un site statique, ça boostera les perfs ! Plus sérieusement, il y a un cache derrière les bloginfo(). La requête se fera une fois, pas deux. Ça me parait raisonnable.

  • Bonjour,
    J’avoue avoir parcouru tres rapidement les commentaires precedents, donc ce que je vais dire est peut-etre redondant …

    Je precise que je ne suis ni designer, ni developpeur professionnel, mais je commence a bien connaitre WordPress, et ses problematiques.

    La plupart de ces articles me genent parce qu’ils sont bases sur l’experience souvent subjective de leurs auteurs. En gros l’experience devient la regle.
    Cette demarche n’est pas la bonne, parce que
    – elle ne tient pas compte, ni des objectifs, ni des ressources,
    – elle correspond souvent a une meconnaissance du produit.

    Les partisants du codage statiques arrivent tres souvent a ce raisonnement, parce qu’ils ont developpe sur des plateformes limitees (herbergement mutualise …). Ils se sont donc focalises sur les performances. Dans ce cas effectivement, lorsque les ressources sont comptees, le statique est plus performant que le dynamique (mais la notion de cache existe). Même chose pour le cote evolutif: si je ne sais pas construire un design capable d’accepter des pages ou des categories supplementaires, je fais du statique…
    Mais lorsque nous avons les ressources, et un design souple, pourquoi se priver des capacites des outils?

    Concernant le manque de connaissance du produit: beaucoup critiques les bloginfo, wp_list_pages, ou les fonctions liees aux categories. Ils rendent donc tout statique, mais en meme temps, ils remplissent la sidebar de widgets en tout genre, pour afficher les derniers articles, les categories, …
    Ceux qui connaissent un peu WordPress, savent que la plupart des options sont chargees en memoire en debut de process, et donc directement accessibles, sans faire appel à la base de donnees, ce qui revient quasiment a faire du statique.
    Meme remarque pour les wp_list_pages, et les fonctions de gestion des categories: les requetes ne sont lancees qu’une seule fois pour toute une page. Donc si ces fonctions sont utilisees dans des widgets, les requetes seront de toute facon executees.

    Pour moi, le statique ne se justifie que dans deux cas:
    – Faibles ressources d’herbergement: mais dans ce cas il faut se poser des questions sur le choix d’un CMS,
    – Design statique: le cas des sites tres graphiques, ou les differents composants sont places au pixel pres. Dans ce cas, nous savons que les evolutions ne sont pas possibles, et que la structure des donnees fait partie du design. Changer les donnees revient a refaire le theme.

    Pour tout le reste (90% des cas), un CMS est fait justement pour faire du dynamique, alors pourquoi s’en priver.

  • Emmanuel > Je ne suis pas tout à fait d’accord avec le dernier point « Pour tout le reste (90% des cas), un CMS est fait justement pour faire du dynamique, alors pourquoi s’en priver. » D’où viennent ces chiffres ? Comme le disait Jean-Pierre Gauffre dans sa chronique d’hier sur France Info (qui au passage ne traitait bien évidemment pas de WordPress mais du monde dans lequel on vit 🙂 ), tout n’est pas noir ou blanc, il y a du gris parfois non ? Et je pense que c’est à ce moment qu’intervient la décision du graphiste/développeur, choisir la meilleure solution (intermédiaire) pour répondre au mieux à la demande de son client pour éviter que 90% des sites dynamiques se ressemblent…

  • @titifrim
    La derniere remarque est de trop en effet … Il s’agit plus d’une expression, que d’une statistique verifiee!
    Mon propos etait de dire que le choix doit se faire, comme tu le souligne, par rapport a des besoins « clients », et non pas de fausses considerations techniques.
    Typiquement, je ne compte plus les sites ou le menu est effectivement statique pour « optimiser », alors que la sidebar est remplie de widgets souvent assez lourds, ou que le site est truffe d’appels a des services exterieurs .

  • Oui la notion d’équilibre et de cohérence dans la façon de gérer la sidebar n’est pas toujours bien respectée c’est certain…

  • D’un point de vue communautaire, je dirai qu’il est préférable de coder en dynamique.

    Beaucoup de web designer et codeurs pensent que le CMS est « un truc d’assisté » justement à cause du ‘tout dynamique ». Ce qu’ils ne veulent pas comprendre c’est que le dynamisme, c’est nous qui le faisons en partant d’une belle base qu’est WordPress.

    Pour rester dans la même éthique d’un CMS, la seule exception à la règle serait de coder un template personnel (que le webdesigner tient à jour) pour éviter d’effectuer des requêtes inutiles.

    Etes-vous d’accord ?

  • Pour mon blog, je mixe code en dur et dynamique, selon le niveau de personnalisation et de simplicité.

  • Ça fait quelques années que je fais du développenment informatique en tant que prestataire de service et forcément c’est le genre de question qui ressortent régulirèrement et quel que soit le sujet je fais toujours la même réponse de normand : Ça dépend.
    Et ça dépend de quoi : du besoin.

    Il n’y a pas d’autres règles : Aucune solution n’est fondamentalement mauvaise à partir du moment où elle permet de répondre au besoin exprimé. C’est la régle que je me suis toujours imposé et avec le recul ça marche pas trop mal.

    Le Besoin, rien que le besoin, tout pour le besoin. Le reste n’est que masturbation intellectuelle.

  • Pour ajouter une couche, il y a aussi le cas de prestataire qui ne connait pas ( ou pas suffisamment) le CMS, et qui préfère avantager le développement, pour gagner du temps.
    Et le temps c’est de l’argent. D’autant que le développement provient des x projets précédents…

    Et en général le client en face en connait encore moins.

    Comme dit LordPhoenix, la base c’est le besoin exprimé du client. Si le client n’est pas précis et pointilleux, la porte est ouverte à l’interprétation (du point de vue de la réalisation).

  • Personnellement, je travaille presque exclusivement… avec un mix des deux. 🙂

    Ou je recode des boucles su mesure si les besoins s’en font sentir. Mais pour ça comme le disent certains commentateurs, il faut très bien connaitre le fonctionnement de wordpress, ce qui hélas n’est pas toujours le cas.

  • Je crois que tout le monde s’accorde à dire que tout dépend du cas, ce qui rentre en jeu :

    La créa
    Le contenu du menu (pages ? catégories ? mix ?)
    Les compétences et les connaissance du développeur
    Le buget alloué ?
    Le nombre d’heures de retard du developpeur ?
    L’objectif du site…

    Autrement dit pas de réponse toute faite, tout dépend la situation.

    Néanmoins, il manque une bonne extension pour pouvoir construire des menus complètement dynamique avec des catégories, des pages, des liens externes, avec la gestion des class active (single, category, page, subpages), etc…

    Un jour peut être 😉

  • Perso, je tape dans le dur direct !!
    mmmmmhhh quel plaisir d’écrire sur Notepad 🙂

  • Comme tout le monde cela dépend des projets, il est évident que si on n’a pas besoin de dynamique pourquoi s’ennuyer a en faire …

    Bel article 🙂

  • Je reste avec le maximum de dynamique, mais il m’arrive d’ajouter une liste de liens à la main. Par exemple, il m’est déjà arrivé de passer du temps à installer des plugins pour extraire les 5 billets les plus lus, alors qu’à la main, on peut piocher 5 articles comme on veut, sans se prendre la tête.

    Pour les fanatiques de l’optimisation, on peut envisager de mettre ce menu dans un fichier à part que l’on appellera par un include. On pourra ainsi le modifier facilement depuis l’éditeur intégré à wordpress.

  • Pour un exemple concret (http://www.tutorial9.net/), si vous voulez coder un menu sur 2 niveaux avec les catégories en première ligne puis les sous-catégories en deuxième ligne, je vois vraiment pas comment le faire sans PHP…

    Mais si quelqu’un sait, je suis preneur ! 😉

  • J’ai abandonné le dynamique depuis quelques mois. Je passais plus de temps à lire le codex, exclure, lister et re-lister qu’autre chose, tout ça pour 3-4 malheureuses top catégories/pages.

    @Maigret : ne s’agit-il pas d’un simple in_category() ?

  • Joel Vennin

    Super article!

  • Personnellement, je pense qu’il faut voir au cas par cas. Et suivant la complexité du menu, voir même le niveau du client. C’est vrai que dans le domaine perso, je préfere 100 fois rester au codage en dur, ne serais-ce que pour l’optimisation de la rapidité du site.

  • Je n’ai pas une grande expérience, mais je pense jusqu’à preuve du contraire que si les fonctions d’appel de menus de WordPress étaient mieux documentées, et si on pouvait prévoir précisément comment ces menus vont se présenter dans les différents cas, et comment on peut les arranger avec les options, je les utiliserais plus volontiers.
    Mon sentiment est que je maîtrise mieux le résultat si je code en dur, notamment avec des menus à plusieurs niveaux.
    🙂

  • Les menus dynamiques sont surtout utiles à ceux qui utilisent le même thème que beaucoup d’autres et préfèrent donc ne pas toucher au code. Mais pour ceux qui utilisent un thème perso, ça n’a pas toujours beaucoup d’intérêt et il peut être plus simple de coder le menu en dur directement dans le thème. On obtient ainsi une parfaite maîtrise du code et on est sûr que les items du menu ne vont pas être chamboulés sans nous demander notre avis à la suite de l’ajout d’une nouvelle page.

  • giorgio

    Bonsoir,
    Je suis en train de construire un site en wordpress et je viens d’acheter le livre WordPress 3 (le campus). Excellent livre. J’ai installé le thème twenty ten qui me convient très bien. La partie qui m’occupe est, non pas la loop des artickes, qui est, je trouve, très bien comme ça d’origine, mais plutôt la navigation sur les pages. (J’appelle pages ce qui n’est pas articles). Donc, ce que je n’arrive pas à trouver (les recherches sur internet parles souvent des articles et peu des pages) c’est comment ajouter une navigation d’une page à une autre (y a-t-il une extension qui fait ça?) qui respecte le cahier de charges suivant: Pouvoir ajouter facilement un format de page qui propose, en haut à gauche, un lien cliquable pour revenir à la page d’ordre précédent (si elle existe) ou à défaut à la page parent (si elle existe). En haut à droite, un lien pour aller à la page enfant (si elle existe). En bas à droite, un lien pour aller à la page d’ordre suivant, précédé du texte « lire la suite ».
    Merci
    giorgio

  • Article très intéressant.

    Pour ma part, il y a les vrais développeurs et les intégrateurs. Dans les 2 cas, ils font des sites, mais ce n’est pas pareil.

    Pour ma part, je suis développeur et je ne fais que du sur mesure afin d’avoir un travail de qualité (code source plus allégé).

    Par contre, ce que je ne comprends pas, c’est pourquoi tout le monde s’obstine à faire du wordpress alors que pour intégrer un design personnalisé c’est aussi long que de développé le site fait par sois-même.

Success, your comment is awaiting moderation.