Bonjour,

Je vais simplifier volontairement mon cas de figure afin de poser ma question :

Je souhaite réaliser un site simple constitué :
- d'un bandeau haut et d'un pied de page,
- d'un bloc de navigation avec un menu (partons sur la base de 7 choix de rubrique),
- d'un bloc 'contenu' qui contiendra le contenu correspondant à chaque rubrique du menu.

Solution de base : en me limitant strictement à du XHTML/CSS, je crée 7 fichiers HTML et un fichier CSS pour la mise en forme. Chaque fichier HTML correspondra à une rubrique, il contiendra le menu ET le contenu de la rubrique.
Problème classique : si je souhaite ajouter/supprimer/modifier une rubrique de mon menu, je suis obligé d'aller modifier le code du menu dans les 7 fichiers HTML.
Or je veux éviter cela pour faciliter les mises à jour ; et d'après mes recherches la solution qui s'offre à moi est l'utilisation de l'inclusion de fichier grâce au language PHP. Jusque là rien de particulier.

A ce stade, 2 solutions s'offrent encore à moi (et c'est là l'objet de mon post) :

• 1ère solution (proposée sur PHPdebutant : http://www.phpdebutant.org/article68.php ) : je crée un fichier HTML contenant uniquement le menu, et je vais inclure ensuite ce fichier 'menu' dans chacun des 7 autres fichiers HTML correspondant à mes 7 rubriques. Avantage selon moi : la navigation apparaîtra toujours dans le code de toutes les pages et le visiteur aura accès à l'ensemble du site, quelle que soit la page d'entrée (par le biais d'un moteur de recherche). Inconvénient selon moi : le code HTML de la structure complète du site (dont l'en-tête HTML, le bloc bandeau et le pied de page) est écrit 7 fois.

• 2ème solution (proposée ici sur AlsaCréations : http://css.alsacreations.com/Tutoriels-PHP/Inclure-un-fichier-dans-un-autre-grace-a-CSS-et-PHP ) : je crée un fichier HTML principal contenant la structure du site dont le menu et un bloc 'contenu' qui incluera (selon le choix du visiteur dans le menu) un des 7 fichiers HTML externes, chacun se limitant uniquement au contenu de la rubrique.
Avantage selon moi : la quantité de code est réduite par rapport à la première solution et il me semble que cette architecture est plus logique. Inconvénient selon moi : si le visiteur accède au site (par le biais d'un moteur de recherche) directement sur une page 'contenu', il lui manquera la structure et la navigation du site pour s'y retrouver.

Alors, quelle est selon vous la meilleure solution ? A défaut d'en préférer une, voyez-vous d'autres avantages et défauts pour chacune ?

Merci d'avance pour votre aide et vos commentaires...
Modifié par grrreg (02 Dec 2006 - 16:53)
C'est assez simple ton equation.
Je te propose de melanger les deux:
Dans ton gabarit, pour le menu, tu inclus un fichier "menu.php"
Dans ce dernier, tu ajoutes un code PHP qui se chargera d'inclure le menu de la categorie en fonction de la dite categorie.

Facile hein !!
Modifié par FrenchFred (02 Dec 2006 - 13:48)
Salut

Il y a un problème de compréhension dans ta démarche. On ne parle pas de site en frames, mais d'inclusion PHP. Ce qui veut dire qu'il n'y a qu'un, et un seul, fichier envoyé par le serveur aux navigateurs.

La technique des frames consistait en un assemblage de fichiers html distincts, qui pouvaient (en principe) exister individuellement. Le navigateur recevait 2 ou 3 fichiers HTML venant du serveur, accompagnés des instructions pour réaliser l'assemblage dans sa fenêtre.

Ici, l'assemblage est réalisé au niveau du serveur. Ton code PHP sert à indiquer au serveur, et non plus au navigateur, quels morceaux de code il faut insérer, et à quel endroit dans la page. Mais le résultat est une page unique. Le menu, le contenu & Cie se trouveront toujours dans le code. Tout ce que PHP fait en réalité, c'est recopier le code qui se trouve dans un fichier "menu.php" dans toutes les pages, pour t'éviter de le faire à la main.

Il est impossible qu'un visiteur arrive sur une page sans menu de navigation, comme c'était parfois le cas avec les frames.
Salut,

Personnellement je procède de la manière suivante :

Chaque page possède son propre contenu et j'appelle la structure du site autour d'elle :

La partie <head> appartient à chaque page, mais j'appelle les métas description, keywords, la favicon et la feuille de style gràce à des includes. Le titre est quand à lui propre à chaque page, donc intégré à chacune.

Ensuite, dans le body, j'ai autant de fichiers que j'ai de zones.
Ainsi, j'inclus :
- mon entête de page qui contient tous les éléments du header (menu accessibilité, titre du site)
- un fichier contenant le menu
(- éventuellement un autre si j'ai un autre menu ailleurs dans la page)
- mon pied de page

Ainsi, lorsque j'ai une modification d'un élément récurrent à toutes les pages, je n'ai qu'à ouvrir le fichier correspondant à la zone concernée et modifier ce que je souhaite, et celà s'appliquera à toutes les pages.
(Sur certaines pages un peu spécifiques il arrive que j'inclus une version B du fichier s'il est différent du fichier initial, mais c'est plutôt rare)

Je ne sais pas si c'est la meilleure des méthodes (n'étant pas calé en php du tout), tout ce que je sais c'est qu'elle simplifie bien la maintenance de mon site.
Modifié par Mikachu (02 Dec 2006 - 14:08)
Par ailleurs, rien n'empêche de réaliser une page qui ne ferait qu'appeller les différents morceaux du site :
<DOCTYPE>
<html>
<head>
   ...
</head>
<body>
   <?php 
      include("header.php");
      include("contenu.php");
      include("menu.php");
      include("footer.php");
   ?>
</body>
</html>
Salut,

toutes les solutions sont en gros équivalentes

. mettre en includes permanentes dans tous les fichiers l'ensemble du code que ces fichiers ont en commun. Et pas seulement le menu, c'est sans doute là que tu ne vois pas ce qui se passe réellement, y compris une grande partie du <head> peut être mis en include ou en plusieurs includes si besoin est. Avec le reste de chaque fichier comprenant ce qu'il à de particulier.


. faire une unique fichier avec tout ce qui sera commun et installé un script d'include conditionnelle pour intégrer aux différente pages à obtenir les contenu particuliers.

La deuxièmes solution exerce une fascination absolue mais c'est bien la première qu'il faut envisager pour un débutant en php.

1. Le mécanisme de l'include est beaucoup mieux compris.

2. Dans la consultation des sources php l'intuition fonctionne mieux. Il est beaucoup plus aisé de se représenter le contenu de quelques includes permanentes que les contenus de toutes les includes conditionnelles. Là encore pour un débutant ça vaut nettement mieux.

3. Chaque page à réellement son adresse correctement exprimée sans passer par les affres de l'url rewriting.

4. Pour le redire ça revient exactement au même

5. il sera toujours temps, l'expérience venant de s'attaquer à l'application particulière que constitue l'include conditionnelle par rapport au mécanisme général de l'include.


Cela dit je sais deux choses :

1. Ce que je viens de dire à de forte chance de n'être ni entendu ni compris. Résister à la séduction et la tentation du pseudo framage semblant au dessus des forces de la plupart.

2. Et ce d'autant plus que les férus de php embarquent beaucoup trop facilement les débutants dans des techniques et des considérations qui suppose un pre requis qui n'est pas du tout présent. Et ça ce n'est pas bien du tout.

Le seul truc sympa c'est qu'on peut ensuite à son aise se moquer de la naïveté dudit débutant. Sauf que ça c'est la marque d'un échec.

Conclusion : pas d'include conditionnelle !

Utilises les includes permanentes, optimise ton affaire et après tu verras.
Modifié par clb56 (02 Dec 2006 - 14:39)
Merci à chacun pour la pertinence (et la rapidité) de chaque réponse.

Toutes ces infos me seront très précieuses et j'espères qu'elles serviront à d'autres qui débutent comme moi avec les inclusions en PHP (il ne me semble pas que cette partie de la question avait été traitée avant...)

pour moi clb56 a bien résumé la chose en différenciant les "includes permanentes" des "includes conditionnelles".

> Réponse particulière pour Sopo :

J'ai bien compris le principe du PHP qui est qu'au final c'est bien un fichier HTML 'pur' qui est généré par le serveur et envoyé au navigateur.

En revanche je ne comprend pas pourquoi un moteur de recherche qui balaie tous les fichiers disponibles sur les serveurs, ne tomberait pas sur les portions de 'menu' ou de contenu qui sont des fichiers de type menu.php ou rubrique36.htm ?
Comment est-on sûr de ne pas avoir le même problème qu'avec les frames ?
grrreg a écrit :
En revanche je ne comprend pas pourquoi un moteur de recherche qui balaie tous les fichiers disponibles sur les serveurs, ne tomberait pas sur les portions de 'menu' ou de contenu qui sont des fichiers de type menu.php ou rubrique36.htm ?
Comment est-on sûr de ne pas avoir le même problème qu'avec les frames ?

Le moteur de recherche ne balaie pas tous les fichiers hébergés, mais tous les liens qu'il trouve à partir d'une page. Si tous les liens pointent vers un index.php, avec des paramètres pour insérer tel ou tel contenu, au final le moteur de recherche n'aura que des pages web complètes, vu que les liens faits pointent vers des pages web complètes.

Le moteur de recherche ne peut pas :
- savoir qu'il y a un fichier nommé menu.php, tant que l'on n'a pas fait un lien direct depuis une page vers menu.php ;
- scanner un répertoire pour faire une liste des fichiers (et puis quoi encore !) ;
- suivre un include vers un fichier, car la fonction include n'est visible que du côté du serveur, et n'est plus présente dans la page web envoyée in fine par le serveur.

Donc pas de souci de ce côté.

Pour ce qui est de l'architecture à adopter, il y a une règle d'or : ne jamais dupliquer un contenu (surtout si ce contenu est susceptible de changer, même un peu).

Que l'on fasse toute une série de pages différentes, qui à chaque fois appellent le contenu de l'élément head, le menu, le pied de page, et qui contiennent elles-même leur propre contenu, ou que l'on fasse une page globale contenant toute la structure, l'élément head et ses enfants, le menu de navigation... et qui n'appelle que la partie variable, c'est à dire le contenu... c'est kif-kif.

Par contre, si on met la même information dans deux fichiers différents, on risque de devoir modifier plusieurs fichiers (voire des dizaines... avec le risque de faire des oublis) dès que l'on souhaitera un changement.
Je n'ai plus d'autres questions, le témoin est à vous (et le tour du sujet de mon post a été fait, en un temps record) !

Merci encore pour l'élégance des solutions apportées...

A bientôt...
mpop a écrit :

Le moteur de recherche ne balaie pas tous les fichiers hébergés, mais tous les liens qu'il trouve à partir d'une page. Si tous les liens pointent vers un index.php, avec des paramètres pour insérer tel ou tel contenu, au final le moteur de recherche n'aura que des pages web complètes, vu que les liens faits pointent vers des pages web complètes.


Pour le dire de manière très triviale, le fait par exemple d'héberger sur un serveur une image qui ne sera jamais utilisée dans un quelconque document la rend totalement inexistante du point de vue d'un moteur de recherche externe. Ce qui n'est pas du tout le cas, sauf conditions expressément indiquées, avec un moteur de recherche interne.


C'est un autre sujet mais je risque néanmoins une remarque ...

Tout débutant devrait installé un moteur de recherche interne, même sommaire, sur son site. Parce qu'un moteur de recherche interne avant même d'être bénéfique pour l'utilisateur aide dans un premier temps le développeur à devenir intelligent et un peu habile.
On peut aussi facilement interdire l'accès direct au dossier (via le .htaccess, par exemple) contenant les fichiers à inclure, pour éviter que ces fichiers soient lus séparément.