plusieurs node dans une page ?

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour à tous,

Le titre peut paraître curieux, mais je suis débutant avec Drupal 6
j'ai lu de multiples sites, vu de multiples tutoriaux vidéos, j'ai une bonne connaissance
(générale)de Drupal
comment on l'installe, on ajoute des modules, les fonctions des modules, les bases pour faire un théme

.... mais
et vous allez me prendre pour un sous-doué

je ne comprends pas comment mettre plus d'un node par page !
(en dehors de views qui permet d'afficher des listes de nodes)

quand je créé un node (article par exemple)
je peux lui assigner une page (avec un alias par ex)

mais si je crée un autre node, que je souhaites afficher sur la même pagelà je ne sais plus faire
ça parait dingue mais je bloque sur ça ... depuis des jours !et je n'ai pas trouvé de ressources sur le net pour y répondre... les tuto arrétent avant ou et prenne juste un exemple avec un seul node sur une page (en général la home page)

comment ajouter autant de nodes (identiques ou différents) sur la même page ?
cette question parait basique, il y a surement un truc que j'ai pas du tout compris dans cet excellent cms qu'est Drupal

j'aimerai vraiment que vous m'aidiez à surmonter cette étape
j'espère avoir été clair

merci à tous!

Version de Drupal : 
Tags : 

Sinon ce que tu peux faire c'est simplement passer par un noeud "encapsulant" :
1/ tu crées un noeud de type "page" qui te servira de page hôte (avec l'url qui va bien)
2/ Tu passes le format d'entré de ce noeud en "PHP" (en activant le filtre PHP dans les modules), et uniquement en tant qu'administrateur.
3/ Dans ton noeud "hôte", tu encapsules tes deux noeuds node/XXX et node/YYY

<?php
  
echo node_view(node_load(XXX), FALSE, TRUE, FALSE);
   echo
node_view(node_load(YYY), FALSE, TRUE, FALSE);
?>

La fonction node_load(NID) va charger le noeud d'id NID (http://api.drupal.org/api/function/node_load), et la fonction node_view va renvoyer la version XHTML du noeud (http://api.drupal.org/api/function/node_view)

Pour une version sans utiliser le filtre PHP, tu peux aller ici : http://arnumeral.fr/node/106

Merci yoran,
je pensais poser une question "stupide"
ta réponse me fait découvrir que la solution n'était pas (a priori) dans les fonctionnalitées de base de Drupal, je me demande bien pourquoi, c'est tellement courant d'avoir ce besoin... enfin moi je le ressens comme tel

pour répondre a la question pourquoi je n'utilise pas views ou même panels
c'est que je pense qu'une solution plus simple qu'utiliser un module pouvait résoudre mon pb.

merci encore Yoran, je vais tester ça mais c'est clair comme explication, je t'en remercie.

Mais je me demande pourquoi Drupal ne permet pas de le faire plus intuitivement, par une simple fonctionnalité de base sans php et sans module en plus.

oups! mise à jour 13H22 :
tu as répondu a ma question ci dessus, j'avais pas bien lu ton message et le lien vers ton site.
Ton site et son contenu force le respect, finalement la clarté de ta réponse a ma question se retrouve dans ton site pro et pédagogique... encore merci)

de rien :)

Je pense que cela ne fais pas parti des fonctionnalités de base de drupal car beaucoup passent par l'usine à gaz qu'est views (et en collant Panel en plus :/).

Sinon, tant que j'y pense, tu as aussi une autre manière de faire souvent oubliée, les blocs. L'idée est d'avoir un contenu principale qui porte l'URL, et de créer un bloc avec le contenu secondaire. Ensuite il ne reste plus qu'à mettre le bloc dans une région de type content_top/bottom avec une visibilité sur l'URL du noeud principal. Cela ne convient pas à tous les usages mais c'est pratique par exemple pour mettre un contenu de type "explication" au dessus d'un noeud (ou d'une liste).

Effectivement
las, je pensais utiliser views et panels, mais a regret.
Au passage tu es mon formateur sur Drupal.

je viens de réaliser que mon livre de chevet, c'est le tien!

A priori au vu de ma question j'ai pas encore tout compris, je vais relire, mais je ne sais pas si tu abordai ce point.

En tout cas ton livre m'a confirmé dans mon choix de Drupal pour mon site web en création.

+1 pour le module
-1 pour le php directement dans le noeud:
Je suis étonné que tu proposes cette solution alors même que sur la page tu la notes dans les "worst practises"!?

Concernant views, ce n'est assurément pas ce qu'il y a de mieux (en particulier en terme de perf) mais pour les besoins "non critiques" et ceux qui n'ont pas envie de mettre les mains dedans, c'est pour moi une meilleure alternative que le filtre PHP.

Tout dépend de la taille de ton projet et de la ponctualité du besoin. Le filtre PHP permet de dépanner de manière simple et rapide, et cela permet aussi de maqueter un futur module. Maintenant on est pas ici dans la section développement et entre deux pratiques je choisi la moins pire. Car installer views et ses milliers de lignes de codes juste pour coller deux noeuds dans une page, cela me semble pour le moins overkill, au delà de ce que je pense intrinsèquement de ce module :)

Je suis donc globalement d'accord avec ton +1, un module custom est pour moi indispensable à tout projet drupal, maintenant je suis plus soft pour le -1 quant les choses sont comprises et gérées en conséquence.

PS: pour le coup du worst practice, faut voir le contexte lorsque j'ai écrit cela. Je reprenais un projet où les "développeurs" avaient collé pas moins de 3000 lignes de code PHP dans des noeuds ET des blocs... Je te laisse imaginer ma tête lorsque je suis tombé là dessus. Ce qui ne les a d'ailleurs pas empêché de coller aussi plus de 200 views (views1, impossible à migrer automatiquement en views2)...

Avec tout le respect que j'ai pour toi, Yoran, il y a tout de même quelques limites dans ton raisonnement. On ne charge jamais Views QUE pour résoudre un seul problème ; s'il s'agit de permettre l'affichage sur un écran du noeud #34 à côté du noeud #98, et uniquement cela, il est clair que Views est inutile. Mais s'il s'agit d'automatiser un affichage dynamique de deux types de contenus liés entre eux (par un node reference par exemple), alors Views sera d'autant plus intéressant qu'on peut l'utiliser pour autre chose. Et concrètement, je veux bien te croire sur les défauts du module, mais je ne pense pas qu'il n'y ait pas quelques raisons au fait qu'il soit si utilisé (même par des développeurs compétents :-)...).

S'agissant du problème présent, je pense que ton interlocuteur n'a pas très bien explicité son besoin. Afficher deux noeuds l'un à côté de l'autre, OK, mais ...

  • s'agit-il toujours des mêmes 2 noeuds (le #34 et le #98)
  • dans la négative, qu'est-ce qui lie les deux noeuds : un nodereference, l'auteur commun, un terme de taxonomie ?...

Parce que si c'est un node reference, par exemple, la solution est toute trouvée (dans la configuration de l'affichage des champs, on peut afficher le noeud référencé complètement). Sinon il existe des petits modules d'insertion d'un noeud dans un autre (Insert Node, je crois qu'il y a un Embedded node ou qqc du genre dans les modules Maison Blanche, etc.). Si c'est l'auteur ou un terme de taxo, je penserais plus spontanément à Panels qu'à Views mais il y a peut-être un module plus léger correspondant exactement à ce que veut christian17 (Panels est énorme parce qu'il permet de tout faire)...

Je ne te suivrais pas sur cette pente pour le moins glissante du développeur compétent Marie-Hélène :) Et de toute façon je ne suis moi-même pas compétent pour répondre avec Views (ou Panels d'ailleurs) que je n'ai pour l'instant jamais eu besoin (ni le désir, évidemment) d'utiliser. Je ne suis qu'un développeur qui aime le code, et juste le code. A ce titre Views et Panels me font flipper tant je trouve plus simple de coder une requête que de me frapper une interface sortie d'un film de David Lynch pour en plus se retrouver bloqué comme un âne devant des besoins simple (ex. un filtre commun à deux onglets représentant deux vues d'une même liste). Sans parler des problématiques de déploiement et de performances. Maintenant quant à savoir pourquoi ce module est utilisé ? J'ai un développeur que je juge compétent à qui je demandais récemment pourquoi utiliser le module "context" (une autre belle usine à gaz) alors que 3 hooks bien placés auraient le même résultat, m'a répondu "ben si on commence comme cela, on n'utilise plus drupal"... J'avoue être resté un peu interdit devant cette réponse.

Ceci étant dit, ce qui est intéressant dans les cas de figures que tu énonces, c'est que pour moi, quel que soit l'origine du besoin "2 noeuds dans 1 noeud", j'aurais finalement toujours la même réponse codée à une ou deux lignes près. Avec l'approche "tout en module", on se rend compte qu'il faut soit se coller à une usine à gaz comme views, soit développer une science "du module qui va bien" alliée à une autre science du "mon petit doigt m'a dit qu'il fallait cliquer ici" que j'admire autant qu'elle m'est étrangère. C'est peut-être pour cela finalement que j'aboutis toujours sur une réponse commençant par la création d'un module custom, c'est juste beaucoup plus simple pour moi ;-) Doit y avoir un relent de choc générationnel derrière tout cela ;-)

Générationnel peut-être pas (tu te la joues ancien combattant, aujourd'hui ? :-)), mais culturel certainement. La logique "CMS" est précisément faite pour éviter d'avoir à coder des requêtes : d'une certaine façon, ton développeur a raison ("si on commence comme ça.."). Après, je sais que Drupal est aussi un framework et donc fait pour permettre aux développeurs de s'amuser eux-mêmes (tout le monde a ses petits vices après tout :-)).

Ceci dit, coder une requête ou un module custom est certainement plus simple pour toi ; la question est : qu'est-ce qui sera plus simple pour le développeur qui te succèdera : devoir plonger dans ton code (quand bien même il serait propre et bien documenté, ce dont je ne doute pas) donc dans "ta logique à toi", ou trouver un module qu'il aura déjà utilisé sur un autre site donc qu'il connaîtra bien ? question rhétorique évidemment, car il n'y a pas une réponse générale (ça dépend de ton successeur, du module en question, etc...). Mais question tout de même...

Non, tes remarques ne sont pas rhétoriques, elles sont mêmes très justement posées.

En fait, en te lisant je me rends compte que nos deux visions de Drupal différent avant tout par l'usage que nous en avons l'un et l'autre (je m'avance peut-être un peu, on va voir :-).

Ton usage de Drupal semble être celui d'un logiciel de gestion de contenu relativement clef en main comme peut l'être Wordpress (en plus puissant et compliqué ;-), permettant de construire des sites qui sont totalement centrés sur ces contenus (comme peut typiquement l'être un blog ou un site documentaire), et ce, sans avoir à ouvrir le capot. Dans cet usage ces modules sont autant des briques fonctionnelles venant renforcer l'édifice mais qui réponde à une série de besoins très standards.

Maintenant mon usage de Drupal est celui de quelqu'un que l'on emploie pour construire des applications web collant à une demande, et où l'aspect "contenu" n'est finalement, au mieux qu'une composante importante, au pire qu'une fonctionnalité parmi d'autres. Dans ce cadre d'usage, Drupal est pour moi un très bon cadre applicatif, et les modules un outil d'architecture logiciel. Du coup, les modules "tout fait" doivent répondre à 100% d'un besoin sans ajouter "de graisse supplémentaire et inutile". Car il y a dans un cahier des charges de base un sacré paquet de besoins qui sont eux non standard, et si je ne faisais pas gaffe, je terminerais mes projets avec d'immenses usines à gaz de 200 modules plus ou moins branlants.

Ceci étant dit, j'entends bien ton argument sur la maintenabilité de sites "codés". J'y répondrais en te disant que cela ne change malheureusement rien. Entre un projet construit à partir de 300 modules différent (exemple non imaginaire...), une dizaine de modules "features", du "context", du "panels" et 200 vues/views (tu peux imaginer la clarté des noms de vues, au bout de la 100ieme on est plus très loin du tutu/toto ;-)) et un projet utilisant une 30aine de modules et une poignée de modules customs, il n'y a aucune différence en terme de maintenabilité. Dans les deux cas, si tout n'a pas été parfaitement documenté, que le pauvre développeur qui arrive sur le projet se trouve fasse à 200 vues ésotériques et 70% de modules qu'il n'a jamais utilisé, ou un code sans aucune documentation, il sera tout aussi paumé.

Tu as parfaitement raison. (sur tout!)

C'est exact qu'on tombe vite dans la boulimie de modules et je comprends bien qu'écrire un module bien ciblé est plus efficace que combiner 50 modules communautaires mal adaptés. Comme personnellement je ne sais pas coder, je vais chercher dans les modules la solution à mes problèmes (au moins les plus drupaliens d'entre eux) et en effet, je me concentre sur le contenu du site.

Mais pour en revenir à Viouze, mes investigations dans la communauté me laissent penser que même des "vrais" développeurs (que moi je l'utilise, ça ne compte pas parce que de toutes façons je ferais pas de site avec Drupal si Views n'existait pas) y ont recours et même pour de gros sites. Donc, si je comprends le fondement technique de tes réserves à l'égard de Views (les quelques requêtes SQL que je sais écrire me donnent juste assez d'expérience pour trouver celles de Views effroyables), il me semble que tu es un peu isolé (après, c'est peut-être parce que tu es le seul à les exprimer). Je ne crois pas en l'infaillibilité de la vox populi, mais de là où je suis me dis que tout de même, il doit y avoir quelque chose derrière cette (quasi) unanimité...

Le réel fondement de mes réserves à l'égard de Views tient à ce que cet outil n'est rien d'autre qu'un générateur de requêtes et que s'il veut devenir aussi versatile que le langage qu'il cherche à cacher, il ne peut que devenir aussi complexe. Et à ce stade on peut légitimement se demander où se trouve l'intérêt de passer par un intermédiaire aussi contraignant, mais moins efficace, que l'original. Pour moi cet outil a son usage pour les gens comme toi, mais pour un développeur, j'avoue ne pas comprendre...

Maintenant peut-être devrais-je plus fréquenter cette communauté de sorte à me sentir moins isolé ;-p

Bonjour,
bon, je déterre un peu le post mais...
Je souhaite pour une page d'accueil avoir une mise en page différente de celle du template général. une page d'accueil avec 4 blocs, j'avais dans l'idée de créer 4 nodes et de les appeler dans le node "maître" affiché en homepage.

Ta solution est simple et super efficace. mais par contre, les autres nodes sont écrits avec tinymce, et lorsqu'ils sont affichés via le node maître, la mise en page est KO : les balises html apparaissent, et tout s'affiche en texte normal
la faute à tiny qui me transforme les < en &lt
;-(

Quelqu'un aurait réussi la manip avec des nodes créés avec un éditeur de texte ?

Justement, est-ce que l'utilisation de BLOC n'est pas une solution ? créer 4 blocs, et éventuellement un template spécial pour la page d'accueil ? avec une région spéciale pour l'accueil, histoire de bien les dissocier ?

Sinon dans le page-front.tpl.php on doit pouvoir utiliser la solution de Yoran, avec les node_load et node_view, puisque dans ce cas on maîtrise le code php ...