Bonjour à tous amis Zér0s

Je viens aujourd'hui avec une question que tout le monde s'est certainement posée un jour, et bien que j'ai déjà vu beaucoup de façons de faire, en apprendre d'autres ne peut être que bénéfique ...

Voilà le problème: Quand vous créez un site web en PHP, vous ne savez jamais vraiment par où commencer, et surtout, comment organiser votre code ... C'est un peu la question que je vous pose ...

Le but de ce topic n'est pas que chacun donne sa vision des choses, le mieux serait de trouver et d'argumenter des façons de faire, d'en améliorer une et de nous faire une sorte de "best-of" des façons d'organiser le code de son site ...

Je me permet de commencer le débat ...

Tout d'abord il y a plusieurs façons de programmer: soit on appelle une page PHP pour chaque type de script, soit on appelle toujours index.php au travers duquel on inclus les fichiers php correspondant à chaque type de script.

Ensuite on peut utiliser des templates ou non, ça ne change pas grand chose, je vais les prendre en compte pour le débat mais il est tout aussi aisé de les mettre de côté ...

Tout d'abord l'architecture des fichiers ... La toute première que j'ai créée était comme ceci:

projet/
projet/index.php <=> redirection vers accueil.php
projet/accueil.php
projet/livreor.php
projet/templates/accueil.tpl
projet/templates/livreor.tpl
projet/images/

Les deux seuls scripts ici sont donc l'accueil (news) et le livre d'or.

Ensuite j'ai appris, ici-même, à séparer les requêtes SQL du reste du code via un dossier "lib" qui contenait également les classes. J'ai toujours été émerveillé par cette façon de faire: chaque "action" sur un script est dans un fichier différent. Chaque script utilise un dossier qui lui est propre. Par exemple:

• lib
  
  • accueil
    
    • add_news.php
    • del_news.php
    • edt_news.php
    • add_commentaire.php
    • del_commentaire.php
    • edt_commentaire.php
  • livreor
    
    • add.php
    • del.php
    • edt.php
  • class.sql.php
  • class.cache.php
  • class.templates.php
• templates
  
  • accueil
    
    • accueil.tpl
    • news.tpl
    • add_cmt.tpl
    • edt_cmt.tpl
  • livreor
    
    • accueil.tpl
    • add.tpl
  • design_base.tpl
• images
  
  • ...
• caches
  
  • ...
• index.php
• accueil.php
• livreor.php

Tous les fichiers passent par index.php, qui se charge d'appeler les classes présentes dans lib ( class.sql.php, class.templates.php, class.cache.php, etc ... ) Des caches pouvaient être générés pour certaines pages et étaient stockés dans le dossier "caches" à la racine.

class.cache.php se chargeait ensuite de vérifier si une version cache à jour existait et la chargeait si toutes les conditions étaient remplies.

Voyez-vous des améliorations à apporter à ce modèle ? Ou avez-vous un modèle radicalement différent à me proposer ?

C'est un débat totallement ouvert, on peut dévier sur des sujets tels que la gestion des sessions mais essayons simplement de rester constructifs

Personnellement, je préfère donner des noms plus courts à mes dossiers :

templates -> tpl
images -> img
upload -> up

C'est un détail certes, mais quand on se retrouve avec des url du genre /templates/designs/ ca soule vite

Et sinon j'ai pas l'habitude de créer un dossier pour chaque section, mais c'est à voir, peut-être que si le site contient énormément de pages, ça peut aider.

je pense qu'il est quand même plus simple et abordable de développer son site à
l'aide d'un framework ( style Symfony, CakePHP ... )

un site en PHP à partir de Zéro, c'est assez fastidieux a faire ( pas forcément difficile, mais bon )

C'est sur que l'arborescence que j'ai donnée est à peu près celle du SdZ, qui n'est plus un petit site

D'un autre côté l'utilité n'est pas seulement de splitter le site en dossiers, c'est surtout d'avoir chaque action dans un fichier bien spécifique, ce qui permet, en cas de bug, de savoir directement où chercher pour corriger l'erreur ...

Salut !

Pour le developpement de mon projet mon organisation est similaire à la tienne Shepard, je mettais meme posé la question de separer les requetes SQL qui devenaient vraiment grosses.

/.. :

• index.php
• /style
• /include
• /lang

Style/ :

• /img
• style_base.css
• style_basic.css
• style_divers.css

Style/img :

• /princ
• /ico

/include/ :

• function.php (le fichier crucial du site)
• /func (fichier ou l'on trouve les fonctions créé par moi-même)
• /class (toutes les classes du site)
• /js
• /libs (jpgraph, PhptoPdf)
• /incinto (on trouve tous les dossiers des pages du sites)

/include/incinto/professeur_classes_secondaires/ (ex) :

• liste_absence.html
• absent.html
• trimestre.html
• eleve_matiere.html
• horaire_cour.html
• add_horaire.html

/lang/ :

• fr
• en
• es
• ...

Je me dis que l'idée de mettre les requetes dans un fichier séparé est superbe, je devrais mettre cela dans incinto/req_sgbdr/nom_du_fichier.html

Ma page est index.php à la racine du site, elle inclue les pages demandées avec le fichier lang qui est propre à une page.

Le fait d'ajouter le support des langues est intéressant, tu gères ça dans la BDD, dans les templates ou dans des fichiers de configs seuls ?

La gestion des langues se fait tout betement dans des fichier de config seuls.La base de donnée peut être un bon moyen mais c'est pas top je trouve.J'essai d'éviter au maximum les acces a SGBD.

Si j'ai un fichier dans /include/le_fichier.php
On retrouvera exactement le meme fichier /lang/le_fichier.php

Si celui-ci n'existe pas, on est redirigé sur la page /include/langue.php pour designer une autre langue.

Mes pages ont une syntaxe assez utiles je trouve :
/?p=professeur_classes_secondaires&do=absent

p = la page que /index.php va ajouter, si incorrect redirection sur l'accueil
do = la page qui est ajouté par p , si do est incorrect on retombe sur l'accueil de p

Avec l'URL REWRITE je pense pouvoir arriver à :
dir/professeur/classes/secondaires/do/absent

ah pas con

Personnellement j'utilises ça:

Chaque page a plusieurs actions: 1, 2, 3, 4, ...

Chaque numéro correspond à une action. Par exemple pour la page d'accueil: 1 = afficher la page d'accueil, 2 = afficher une news et ses commentaires et le formulaire d'ajout, 3 = Ajouter un commentaire dans la BDD, 4 = Accueil de l'administration des news, ...

A chaque act correspond le fait qu'il faut charger le système de templates ou pas, par exemple l'act 3 dans ce cas-ci n'a pas besoin des templates, juste du script de redirection une fois que le commentaire a été ajouté.

L'url est toujours comme ça:

index.php?page=nom_de_la_page_php&act=nom_de_l_action&id=id_principal&id2=id_secondaire

les id servent à diverses choses en fonction du script, la plupart du temps, pour les news, il s'agit de l'id de la news. id2 sert plus rarement, mais parfois il est nécessaire ( déplacement d'une news via un lien: déplacer vers le haut (1) ou vers le bas (2) est stoqué dans id2 ).

D'autres arguments peuvent être ajoutés bien sûr, mais ne sont plus gérés par index.php directement ( sécurisation et vérification )

Pas mal le act, je n'aurais pas pensé à ajouter quelque chose du genre.C'est vrais que ca peut être super utile.

Je pense qu'il est bien aussi que chaque erreur dans le code php ou SQL devraient être rapportées automatiquement aux administrateurs dans un dossier /rapport.Cela pourrait faciliter les feedback.Les sites comme le siteduzero pourrait utiliser un systeme du genre (peut etre ca l'est deja).

Le fichier template est chargée par /index.php ou c'est par le fichier en question ???

Pour la gestion des templates, il y a plusieurs possibilités, celle du SdZ est d'utiliser la classe codée par karamilo, vraiment excellente, malheureusement réservée au SdZ, je pense que je vais la recoder comme je peux ...

En gros les fichiers sont chargés par le module du script présent à la racine ( ainsi c'est accueil.php qui charge le template qu'il a besoin en fonction de l'act ). Comme les templates peuvent s'imbriquer c'est plus simple.

Pour ce qui est des rapports c'est réellement une bonne idée, mais pas pour toutes les erreurs, celles qui ne devraient pas se produire doivent évidemment être rapportées, mais les erreurs de la part de l'utilisateur doivent être "sautées" ...

Associer à chaque erreur un statut de rapport ( 1 = pas de rapport, 2 = rapport dans le dossier "alert", 3 = rapport dans le dossier "warning", 4 = rapport dans le dossier "fatal" ) ou un truc du genre est peut-être une façon de faire ... ?

Je ne sais pas trop si ma question est dans le bon sujet mais elle a un rapport avec l'organisation d'un site en php.

Je voudrais savoir s'il vaut mieux:

• faire une page de "base" avec tout le design, les menus, la bannière et tout puis inclure ensuite le contenu de chaque page grâce à une variable $_GET['page']
• faire une page "entiere" a chaque fois et inclure le menu, la bannière...

Merci de votre aide et desole si je suis pas au bon endroit

Perso... pour mon (futur) forum voilà comment je compte procéder :

Citation : Mon arbo

~/admin/*.php
~/admin/general_config/*.php
~/admin/droits/*.php
~/admin/forums/*.php
~/admin/users/*.php
~/admin/mods/*.php
~/admin/styles/*.html (fichiers TPL)

[...]

~/templates/
~/templates/nom_du_dossier
~/templates/nom_du_style/*.html (répartis dans d'eventuels sous dossier, on verra plus tard)
~/templates/nom_du_style/langs/
~/templates/nom_du_style/langs/langue_abregée/ (fr, en, etc) (répartis en dossiers par images, éventuellement ; ne contient que des images)

~/langs/
~/langs/langue_abrégée/*.php (fr, en, de, etc)

~/javascript/*.js

~/includes/*.php (inclusions de fichiers nécéssaires au démarrage)
~/includes/classes/classes_*.php (les différentes classes)
~/includes/fonctions/fonctions_*.php (les différentes fonctions)
~/includes/db/db_*.php (les différentes dbal utilisées)

~/install/*.php (le fichier d'installation, et on verra après :p)
~/install/schemas/*.sql (les instructions SQL suivant le dbal choisi)

~/images/*.png (les différentes images)

~/cache/
~/cache/tpls/*.php (les TPLs parsés, n'ayant pas subi de récentes modifications)
~/cache/sql/*.php (les résultats SQL à stocker. Devrait pas topr y'en avoir : la config, les forums, les membres connectés, les membres...)

~/utils/*.php (différents programmes "sympas" (faudra voir son utilité, mais ca peut toujours servir)

~/*.php (les fichiers de base)

En gros, dans mes include, mes fichiers qui sont vraiment nécessaires et qui contienent les trucs "vitaux" à mes différents scripts.

Sinon, sur mon site "SanctuaireFF", je procède d'une manière quelque peu diférente (quand on fait des veux trucs ca s'entasse, mais en général, de mon coté, j'essaye de corriger peu à peu en un truc plus abordable) :

Citation : Autre type d'arbo

~/admin/peu pres comme shepard, une action par scripts puis appelé par une page index. =D

~/include/ mes fonctions, ma config, et deux trois trucs vitaux au site

~/mes pages, souvent préfixées pour repérer (souvent inclues dans les pages principales du site). Par exemple, ff7_presentation.php ...

Franchement pas mal ce sujet

Oui c'est vrai que juste certaine erreurs devraient être rapporter.On peut en effet leur apporter chacune un ID pour differencier les niveaux.

/rapport :

• 2 = alert
• 3 = warning
• 4 = fatal

Cela peut être deja tres utile, on va sur notre partie admin, on est immédiatement avertie du nombres d'erreurs dans le fichier rapport, apres dés que c'est lu ou noter comme réglé ce fichier est supprimé.
A un certain niveaux, ou un nombre vraiment trop nombreux on peut décider que le systeme met le site en maintenance.

jejesochalion > Personnellement, je procède de plusieurs pages "basiques" avec un header et un footer, et j'utilise aussi les $_GET (je sécurise le tout, evidemment). Donc c'est du "hybride" et perso, je préfère ca

On pourrait aussi, sur rencontre d'une erreur "fatal", empêcher l'accès juste à la partie du site concernée, mais ça devient assez hasardeux à faire ...

jejesochalion > Personnellement j'utilises les templates, et en particulier un template "de base" qui contient tout le design du site et une variable {CONTENT} dans laquelle je charge les templates générés par mes différents scripts.

En y réflechissant mieux ca peut être très facile à mettre en place (je me creus ela tete depuis taleur pour cela aussi lol ).

Bon comme on a dit on a nos dossier, mais dans ce cas là on s'interesse juste au dossier fatal.

/rapport/fatal/
membre_edit_profil.php

On est daccord que l'on est sur une structure où l'on centralise tout le site avec une page accueil ou index.php peu importe.Pour mon exemple je vais utiliser index.php (j'utilise ca lol):

La page doit avant d'affichier la page demandé verifier si cette derniere n'est pas presente dans ce dossier fatal.


Je ne pense pas que ca prend enormement de temps de verifier avec php si un fichier existe ou pas grace a is_file().

On voit réellement que une structure centralisé peut être très utile !

EDIT :
Maintenant il faut lister ce que l'on appel erreur fatal .

Citation : Gaga971

On voit réellement que une structure centralisé peut être très utile !

Certes, mais lourde. C'est pour ca que je parle d'une structure hybride : c'est à dire on découpe les grosses sections (index, forums par exemple), et dedans on fait le traitement des pages liées à ces sections. Du moins c'est comme ca que je procède^^

MAis c'est quoi ce vieux htmlentities ?

C 'est même pas htmlentites lool
Une struture "hybride" est identique à tes découpages de sections.On utilise dans des dossiers en amonts pour chaque page (include), des feuilles qui lui sont propres (incinto).
Il y a rien de lourd dans cette structure ; après faut savoir l'organiser, pour que le reperage soit facile aussi.

Scuse, j'ai parlé trop vite. Enfin, specialchars, pas terrible non plus remarque.

Mais la structure tout concentré en index, ca peut devennir assez vite lourd (je sais de quoi je parle) -.-

Peux tu developper pour le "lourd".A quels niveaux ??

Au niveau ou tu ne peux aps tout gérer le contenu des pages par SQL, entre autres. Au niveau ou tu as plus d'une 100aine de pages à gérer dans ton fichier index. Par exemple.

Au niveau ou je peux gerer tout le contenu des pages par SQL ?

La première , je ne vois pas trop pourquoi ou j'ai du mal comprendre

Pour la deuxieme c'est un pas un probleme non plus , en tout cas pour moi l'utilisation du array ne met pas obligatoire.Car la variable $_GET['p'] contient le nom de la page a inclure juste sans le ".php".Apres je n'aurai juste a verifie si le fichier existe dans le dossier concerné.

J'avais déjà préparé cette eventuelle chose qui est enervante à force.

Après il faut verifier si il y a pas (ou de mauvais) chemin indiqué dans la variable et autres sécurités pour pouvoir inclure le fichier [...]

Enfin dans ce que je fais je trouve que pour l'instant il y a aucun soucis à se faire de coté (meme un an apres) .

J'avais deja pensé à ce que tu me dis lors de la conception du module (enfin le deuxieme point).

Intéressant ce sujet .

Perso je suis plus méga-fichier, c'est-à-dire que je centre toute une catégorie dans un seul fichier (forum.php, admin.php, ...) où dedans il y a des catégories (dans admin par exemple on peux avoir news, groupes, ...) et dans ces catégories des méthodes (ajouter, supprimer, ...) et souvent un ou plusieurs arguments (id de l'élément concerné généralement), et dans l'admin il y a en plus le grin de sel pour éviter les liens piégés.

J'aime bien cette methode car ça evite que son site soit fragmenté en plein de fichiers et qu'on ne s'y retrouve plus dans Notepad++ avec tout les onglets , et je peux très facilement cacher les parties avec les [-] dans l'éditeur .

Exemple pour supprimer un bâtiment :
admin.php?page=building&method=delete&building=4&salt=[GRIN DE SEL]
Dans l'admin il n'y a pas d'URL RW (mais dans le reste du site oui).

Pour la hiérarchie je suis un peux (beaucoup) comme le SdZ :

• Templates -- Tout ce qui concerne l'affichage de près ou de loin
  • templates
    • fr
      • admin
      • forum
      • include
      • -- Ici des templates divers ne concernant pas les cat ci-dessus
  • design
    • css
    • forum
    • image
  • html
    • fr
  • compiled -- Les templates compilés
  • lang -- Les fichiers de langue à inclure dans les modules, par ex. on inclu /lang/forum.php dans forum.php
  • js
  • xml
• libs
  • Upload.class.php
  • sql.class.php
  • functions.php -- Fonctions divers
• upload
  • fr
    • 1_100 -- Les dossiers d'intervalles pour éviter la surcharge et les grosses pertes
    • 101_200
    • 201_300
    • -- etc...
• core.php -- Fichier principal à inclure sur toute les pages
• -- Tout pleins de pages comme admin, forum, connexion, inscription, etc...

Voilà ma minère .

Ma gestion d mon site permet d'acceder rapidement aux pages concernés pour tel ou tel script.
Je separe l'affichage de la gestion. J'ai ma page d'index dans laquelle j'include des pages sélectionnées par l'url. Je gères les pages publiques des pages privées, tout comme les templates.

/index.php
/admin/*.php mes fichiers de configs et fonctions et class
/templates/nom_design/(images|css) gestion du design
/templates/public/mes_fichiers_templates_publics.tpl
/templates/private/mes_fichiers_templates_privées.tpl
/gestion/mes_pages_de_gestion_de_formulaire
/modules/public gestion de l'affichage des pages publics
/modules/public gestion de l'affichage des pages privées
/modules/(news|dossiers|acteurs|roles|galeries|sondages) mes données (j'evite au plus les bases de données type mysql, la gestion par fichiers est très puissantes)
/upload/(grd|mini)
/intermediaires/ page intermediaires pour generer des $_SESSION pour par exemple la creation d'un nouveau pic (j'aime les variable GET qu'on on poste un truc)
/corbeille dossier poubelle en cas de suppresion de news, dossiers ...
/comptes/pseudo/*.inc infos divers concernant les membres (avatar, signature)

J'ai une page resultat.php qui informe tous les résultats des traitements qui ont été effectués.

Donc tout ce passe dans index.php grace aux includes.

Salut,

Très bon idée Shepard.
Voici l'arborescence que j'utilise sur un site actuellement en dev :

• caches
  • fr
  • en
• langs
  • fr
  • en
• libs
  • amis
  • cat
  • config
    • fr
    • en
  • dcode
  • forums
  • mp
  • sessions
• templates
  • ajax
  • compiled
    • admin
    • atom
    • config
      • fr
      • en
    • dcode
    • groupes
    • news
    • ...
  • css
  • html
    • fr
      • coupure.html
      • serveur_down.html
      • mysql_down.html
      • ...
    • en
  • images
  • jstpl.class.php
• upload
  • fr
  • en
• index.php
• news.php
• sessions.php
• ...

Sinon, j'utilise un moteur de templates (un tpl squelette) codé maison et le SGBD PostGreSQL.

En ce qui concerne les erreurs, c'est une bonne idée ça mais ça serait peut-être lourd de répertorier toutes les erreurs, nan ? Enfin, jsais pas trop.

Aussi, au niveau du code, sur chaque fichier, je met à chaque fois, l'auteur, la page (index.php par exemple), la description, la date de création mais pas de dernière modification (en fait, je trouve ça chiant à faire et autant utiliser tortoiseSVN par exemple pour avoir l'historique des versions).

Enfin, au niveau du dev, j'utilise un sous-domaine plutôt qu'un répertoire dev/.

Citation : Mephisto

Enfin, au niveau du dev, j'utilise un sous-domaine plutôt qu'un répertoire dev/.

Pareil =D

Je viens de penser à quelque chose mais je ne sais pas si ça fera avancer le débat ou pas ...

Pourquoi ne pas baser les modules ( livre d'or, forum, etc... ) sur un modèle objet ... ?

Autrement dit chaque module est lui-même un objet qui contiendrait donc les méthodes add, del, edt, ...

Le seul problème étant de tout devoir concentrer dans un seul "méga-fichier" à la manière de Bilbax, mais comme il le dit ce n'est pas vraiment un problème avec un bon éditeur de texte ...

A ma connaissance il est impossible de redéfinir une fonction d'une classe hors de son fichier de création en PHP, mais que quelqu'un me contredise me ferait assez plaisir

Salut,

Topic très intéressant .
J'utilise une structure assez similaire à celle donnée par Shepard. Avec une inclusion de la page correspondant à l'action demandée sur l'index. Je ne sépare pas les requêtes mais c'est une excellente idée.

Vous parliez plus haut de la gestion des erreurs avec éventuellement un log, je vais en profiter pour faire un peu de pub pour mon tuto traitant des fonctions de gestion d'erreurs intégrées par PHP.
Personnellement, je déclenche une erreur de type E_USER_NOTICE pour déclarer que l'action a été effectuée avec succès, E_USER_WARNING si c'est un échec "normal" et E_USER_ERROR si c'est un échec dû à un comportement inattendu du script. Les erreurs par défaut et les E_USER_ERROR sont affichées le cas échéant et enregistrées dans un fichier unique (vidé de temps en temps) mais on pourrait très bien utilisé une db pour le log.
Pour mettre le site en maintenance, on pourrait simplement créer un htaccess redirigeant vers une page d'erreur prédéterminée ou renommer le fichier index pour en mettre un autre à la place, ca permet d'éviter la condition pour chaque page.

Pour l'utilisation de la POO, le problème c'est que tout est dans un fichier, c'est moins pratique pour la maintenance. De plus, si tu n'as besoin que d'une fonction (en général, on a pas besoin de pouvoir ajouter une news lorsqu'on l'édite), tu les charges toutes.

Et pourquoi pas dans ce cas une classe du script de base et des fichiers fonctions ( comme avant ) qui étendent cette classe de base en ajoutant juste la fonction souhaitée ...

Le problème survenant dans le fait d'étendre la même classe par plusieurs méthodes différentes, je ne sais pas si c'est possible, je ne connais pas à fond le système objet de PHP, je vais me renseigner pour voir ce qu'on peut faire ...

Pour le fait de thrower des erreurs c'est pas bête et plus pratique que de tout gérer "à la main" je vais lire ton tuto

Cool ton tuto

Edit:
Pour les classes ça semble trop complexe et finallement est-ce vraiment utile ? C'était juste une folie de passage, que j'aurais certainement assouvie s'il était possible d'étendre des classes dont on ne connait pas directement le nom mais stockés dans une variable

Salut, vous parlez de mettre les requetes séparé du code...

c'est à dire que chaque " $retour = mysql('requete sql') or die (mysql_error()); " sera dans un fichier php à part ?
Et quand on en aurait besoin on l'appellerais avec un include ou require ?


En parlant d'include,
C'est quoi la différence entre include, require et require_once ?