[resolu]Organiser ses sites, ses versions, ses espaces de tests ...

Bonjour à tous (et à toutes !)

Pas de liens dans ma signature sur un site, mais si vous saviez le nombre d'embryons que j'ai sur mon disque, vous prendriez peur !

Je suis à l'état ... embryonnaire !
Heureusement que nous avons un concours du plus beau bébé ...

De temps en temps, je mets une page en ligne ...
Bref, j'ai plein de pages un peu partout, sur des serveurs, de ci de là.

L'avantage de Dream est que, si moi j'oublie quoi et où, lui s'en rappelle !



Bref, étant tout de même assez ordonnée de nature, j'peux plus supporter, il faut que je fasse quelque chose.

Comment organisez vous vos sites, vos espaces serveurs, vos espaces de tests et vos images locales ?
Modifié par Vero (19 Aug 2005 - 18:57)

Un dossier par sous domaine, un dossier par site/sous site

Mon arborescence type en ligne c'est ça :

www
+--| design
+--| images
+--| includes
+--| nomDossierPourSousDomaine
+--+--| design
+--+--| images
+--+--| includes
+--+--| index.html
+--+--| style.css
+--| nomDossierPourAutreSousDomaine
+--+--| design
+--+--| images
+--+--| includes
+--+--| index.html
+--+--| style.css
+--+--| script.hs
+--| index.html
+--| style.css

Etc, structure dossier = site/sous domaine/sous partie, sous dossier = rangement pour les sites, design pour les éléments graphiques de déco, images pour les images de contenu, index.html pour le site, includes pour les éventuels fichiers à inclures etc

Avec des noms de dossier pertinent qui indique ce qu'il y a dedans, et si sous domaine, le nom de sous domaine = le nom du dossier.

Plop,

Moi c'est pas dur, j'ai un schéma général auquel je me plie pour tout mes espaces disques dédiés au développement de site:

Racine :
|___ repertoire dédié aux sites
|___+__répertoire d'un site
|___+___+__inc (classes et librairies métiers)
|___+___+__config (fichier de config et d'inialisation)
|___+___+__contenu (toutes les données destinées à être utiliser en contenu)
|___+___+__template ( html + css )
|___+___+__beta (espace dédié aux tests unitaires ou essais)
|___+___+__archives (archives des précédentes versions)


Voilà j'ai ça sur mon serveur de mon pc, et pareil sur mon hébergement en ligne dédié aux tests.
Modifié par tyx (20 Jul 2005 - 17:20)

Ahh oui aussi !

Fais pareil en ligne et en local
Comme ça tu t'emelle pas les pinceaux, c'est partout pareil.
T'as plus qu'à uploader direct sans te casser la tête à réfléchir où va quoi etc

Et pour chacun de tes sites et sous sites etc, utilises la même "règle" de rangement histoire encore une fois, de pas te casser la tête

Expérience pas vraiment liée à l'arborescence d'un site web mais plus généralement aux partitions locales ou de serveurs:

J'ai rencontré un problème après le crash d'une partition de mon DD alors que j'avais sur CD/DVD plein de sauvegardes me permettant a priori de tout récupérer. A force d'éparpiller sur 2 à 5 PC mes données et de les transférer de l'un à l'autre, je ne savais plus QUOI récupérer sur cette partition! Même en ayant le contenu de toutes les autres et un backup de tout, bah difiicile de savoir ce qu'il pouvait bien y avoir à l'instant t du crash
Heureusement qu'Easy Recovery Pro a réussi à faire un listing sous DOS d'une des FAT (10 000 fichiers et x00 répertoires, ouaiiiis ), ça m'a bien aidé ...

C'est pas le tout d'avoir des sauvegardes, encore faut-il savoir ce que l'on perd lors d'un crash!

Réponses claires et précises, comme j'aime !

Donc, vos répertoires design (de travail) sont aussi sur le serveur ?
C'est à dire que tout ce qui ne sera pas en ligne, vous le sauvegardez aussi sur le serveur (archives, etc...) ?

Bon, et un sous-domaine : c'est quoi au juste, en pratique ?
Que peut-on faire avec ? Et ne pas faire ...
Modifié par Vero (20 Jul 2005 - 17:48)

Chacun ses méthodes.. pour moi :

2 rep sur le DD
+sites en cours+ (dév en cours, pas finis, maquettes, etc...)
+sites en ligne+ (sites terminés et en ligne-> ce dernier rep je ne l'ouvre qu'en cas de màj)

Chaque rep contient des sous-rep au nom du site (utile pour définir des sites dans DW)

Chaque sous-rep contient :
"index. (html/php)" à la racine du site
un ou plusieurs rep images (genre img_pages / img_index)
un rep "scripts" (pour CSS/JS/ etc)
un rep PSD (contient toutes les maquettes images en psd)

Après... après ça dépend : pour un gros site (+ de 50/100 pages) je crée des sous-sous-rep à l'intitulé des rubriques (langues par ex) et pour les petits sites (10-20 pages) je mets toutes les pages html direct à la racine. Les sites avec includes sont systématiquement organisés en sous-sous-rep, avec seulement les "contantes" au niveau 0 : menus, entêtes, etc.

Pour les mises à jour j'ouvre le site concerné dans +sites en ligne+, je le bricole et j'envoie sur le serveur immédiatement par DW, comme ça pas de prob de cohérence entre versions de fichiers. Si c'est une GROSSE màj, je duplique d'abord tout le rep et renomme l'ancien avec la date derrière (style dugenou-juillet 2005) comme ça je sais quelle est la version actuelle et où retrouver les versions antérieures au cas où, et en plus DW ne s'emmêle pas les pinceaux dans sa carte du site... En cas de refonte complète d'un site existant, je recrée un nouveau rep dans +sites en cours+ et je laisse l'ancien à sa place, suivi de sa date limite de consommation... (faut juste penser à recréer l'adresse du site dans DW pour qu'il reconstruise la carte correctement).

Pour les sites en cours j'ai un serveur test consultable par les clients ; dès que c'est OK, je tranfère tout le site sous le nom de domaine du client et je vide mon serveur test. Ensuite sauvegarde sur CD et point barre. En cas de crash je récupère tout soit sur CD, soit par FTP...

Rien de compliqué ni d'extraordinaire mais ça marche bien, j'ai pas prob particulier pour gérer tout ça.

Salut,

pour plus de clarté (online), je m'organise comme suit:

/www/ -> Rien ne pointe dessus (malgré les réglages par déafut de l'hébergeur
<edit>pas tout à fait vrai, ce dossier est accessible, mais par un sous-domaine de l'hébergeur</edit>
/pear/ -> Libraire PHP, inaccessible de l'extérieur
/www/site.com -> ben euh
/www/sous-domaine.site.com
/www/sous-domainebis.site.com
/www/sitebis.com

En fait, je ne voulais pas pouvoir accéder à mes sous-domaines (pour des questions de liens et de clarté d'arborescence dans les dossiers du nom de domaine principal) par h ttp://www.site.com/sous-domaine.

M'enfin toussa (c), des goûts des couleurs

Par contre, sur mon disque, c'est le foutoir !

@+, HoPHP
Modifié par HoPHP (20 Jul 2005 - 18:33)

HoPHP a écrit :

Par contre, sur mon disque, c'est le foutoir !

Ben, moi aussi.

Avant de m'y remettre (avant de vous rencontrer !), c'était bien rangé (!) :

Sur mon disque :

un espace "sites" image des versions en ligne, racine du serveur local

un espace "travail" pour chaque site, ailleurs sur le disque

Sachant que je ne travaillais qu'un projet à la fois, il m'était facile de faire mon archivage, ménage, dépoussiérage et rangement du placard, une fois le projet terminé.

Maintenant que je vous connais et que je fais 36 choses à la fois (!), mon organisation en répertoire de travail local ne facilite pas la mise en ligne facilement.


Je me retrouve avec :

4 espaces d'hébergement

Dans chacun, je peux avoir plusieurs sous-répertoires avec des projets différents, en rapport, pas en rapport ... ???

Donc, là, j'aurais intérêt à créer des sous-domaines ?
C'est à dire : on peut limiter les accès sur un sous-domaine ?

Comment ca marche ?

Vero > vaut mieux ne pas tout mettre en ligne , il y a des trucs qui n'ont à priori rien à y faire, enfin tout dépend

Mais avoir la même structure en ligne et en local me parait indispensable

Pour les sous domaines c'est ça :

http://www.monnomdedomaine.com => ton site "racine", www optionnel
http://tonsousdomain.nomdedomaine.com => le sous domaine "tonsousdomain" qui, si tu suit ma méthode plus haut pointera en fait vers le dossier "tonsousdomain" ce qui equivaudra donc à http://www.monnomdedomaine.com/tonsousdomain/

Je trouve ça plus propre, plus parlant, surtout si les sous domaines sont en fait d'autres sites.

Tu auras une illustration de la chose pour mon prochain "site" qui sera en fait un groupement de petits trucs.

J'aurais par exemple
http://www.olivier-patry.net qui sera une sorte de page "aiguillage" qui présentera l'ensemble des mes trucs et donc, j'aurais des parties
http://tutoriels.olivier-patry.net
http://cv.olivier-patry.net
http://dev.olivier-patry.net
http://films.olivier-patry.net
http://fac.olivier-patry.net

etc chacun pointant vers le dossier RACINE/tutoriels, RACINE/cv, RACINE/dev, RACINE/films, RACINE/fac parceque je m'organise comme ça, mais ce n'est pas non plus une obligation, c'est juste plus clair

A priori oui, tu peux limiter les accès sur tes sous domaines, à voir avec ton hébergeur, finalement un sous domaine c'est juste l'accès à un dossier sur ton arborescence, libre à toi de bloquer l'accès à ce dossier et à ses dossiers enfants.

Tu n'es pas obligée de passer par les sous domaine, tu peux directmeent pointer tes urls vers les dossiers. Mais avec les sous domaines, tu sépares (visuellement surtout) bien les choses et tu sais que ce sont des choses différentes.

En fait, j'ai intérêt à me payer un hébergement pour gérer facilement cette histoire.

Pour la partie perso, je suis encore chez free ...

Là, je goûte à Celeonet pour le site de l'association : y'a pas photos !

Mais je ne vais tout de même pas m'installer au même endroit pour mes tests en ligne de feuille de style de "quand j'ai besoin d'un coup de main" !

En plus, si on rajoute les blogs, bases de données et tout le Saint Frusquin !

Ah ! Petite Vero, il faut monter d'un étage ...
C'est fini la petite vitrine ... il va falloir aménager au moins un 4 pièces !

Allez : Ho hisse !

Garde donc ton zoli celeo !!

Moi j'ai ça et ça roule tout seul.

J'héberge dessus, blog, tutos, portfolio, une liste de film gérée via PHP et base de donnée (mais accès restreint, enfin accès public ça ferait pareil), et j'ai un dossier "bordel" où je fous les trucs pour aider les autres, mes trucs en attentes, mes tests, etc

Ca roule nickel !

Pour l'instant c'est simple, j'ai deux arborescences, une pour le site de la mairie, une pour le site du MC et ses "enfants" (bob/kekchose)

Sur les serveurs, j'ai juste les sites, avec un repertoire pour les includes, les photos (celle que j'ai faite), un pour les miniatures des photos, un pour les images (boutons, fonds, bullets...), le site de la mairie étant plus complexe avec un répertoire par chapitre.

Sur mes postes locaux, j'ai exactement la même arborescence et les mêmes tables MYSQL (aussi sur un disque externe et sur CDRW, voir sur clé USB pour le site que je bidouille en ce moment) et un répertoire parallèle pour les fichiers images originaux, les documents de base au format Word, les rejets (fichiers obselètes, tests divers...)

Bref disons pour le site mc

easyphp
*www
*mc
*+include
*+photos
*+mini
*+images
*+bob
*_+images
*_+photos
*_+mini
*_+golfe
*__+images
*__+photos
*__+mini
*_+les autres sites...
*mc2
*+ori images
*+rejets
*+documents
*_+divers
*_+ori txt
*mairie
*routines php (pour tester des trucs des sites de formations, de scripts, des articles de php solution...)

Comme cela pour les tests, je mets dans www les fichiers et répertoires de mc ou de mairie et pour le ftp, pareil...

Sauf que l'autre jour en passant du site de la mairie à celui du MC, j'ai bêtement tout copié dans mc et donc mélangé deux sites différents avec des fichiers qui ont le même nom (fallait bien que je merde un jour, 7 ans que ça marchait)
Modifié par Bob (MC Melun) (20 Jul 2005 - 22:35)

Alors, en pratique, je me pose certaines questions :

J'aimerais pouvoir conserver mon organisation actuelle en local, à savoir, deux disques dont un dédié au foutoir en cours et l'autre plutôt destiné à l'archivage récent et "en vigueur".

Je considère les tests comme le foutoir ...

Je me retrouve donc avec une version officielle sur un disque et les test sur un autre.

Par contre, en ligne, tout va être regroupé sur le même serveur ...

Et ce pour chaque dossier ...

Disque1.www.A -> domaine A
Disque2.tests.A -> domaine A

Disque1.www.B -> domaine B
Disque2.tests.B -> domaine B

Mais est-ce que je peux organiser l'espace distant de cette manière :

www -> www paramétré en domaine
tests -> tests avec un sous-domaine correspondant pour ce répertoire

et non :

tests -> www/tests

A priori, je peux le paramétrer ainsi chez mon hébergeur ...

Etant donné que le client ftp gère les répertoires locaux et distants, une fois bien paramétrés ces derniers devraient gérer ce "chassé croisé".

Et cela correspondrait mieux, en fait, à l'image de mon organisation locale ... en limitant l'arborescence sur un projet. (Quand je fais des tests, je ne fais pas de mises à jour du site ...)
J'ai le sentiment que je me ferais moins de noeuds, justement !

Vous en pensez quoi ?

De plus, comment cela marche t-il pour la "famille php" : y a t-il "un moteur central" ou est-il nécessaire de réinstaller pour chaque version ?

C'est une question plus liée à php dont je ne maîtrise pas les contours, mais je prends la facilité de vous la poser ...

Bonsoir Vero

Ma réponse va faire remonter ton sujet... mais elle ne sera pas complète, je n'ai pas encore attaqué la gestion de sous-domaine, je n'en ai pas encore le besoin.

Pour php, je ne comprend pas bien ton soucis. php est géré côté serveur.
Le script est envoyé au parseur (le truc qui interprète php) puis le html généré est envoyé au navigateur. Donc le php est le même pour les milliers de sites hébergés sur le même serveur.

Edité : je suis aussi allé sur les pages d'aide de ton hébergeur, mais je n'ai rien trouvé...
Modifié par dominique (28 Jul 2005 - 17:25)

Vero a écrit :
De plus, comment cela marche t-il pour la "famille php" : y a t-il "un moteur central" ou est-il nécessaire de réinstaller pour chaque version ?

PHP n'est pas dans le coup !

Il y aura un seul et même PHP pour tous tes sites, quelle que soit l'arborescence mise en place...

Par contre, ce que tu devras règler finement, c'est le paramétrage d'Apache, de façon à ce qu'il puisse démarer son localhost sur plusieurs répertoirs différents selon ce que tu veux tester...

Perso, j'ai pas compris comment faire (je crois que c'est avec les alias mais je n'ai franchement pas pris le temps de comprendre comment ça marche) et j'ai pris la solution de facilité :

- Tous mes sites en tests sont dans le localhost défini pour Apache (WWW)
- Tous mes sites pas en test ne sont pas dans WWW

Je copie donc depuis WWW vers son lieu de stockage le site que je ne teste plus et je copie dans WWW le site que je veux tester depuis son lieu de stockage

Le lieu de stockage peut par exemple être tes arborescences sur deux disques

Enfin pour le site MC et ses enfants, c'est pas tout à fait cela, voir mon message plus haut...

Salut,

Concernant l'arborescence, j'utilise 3 répertoires principaux...

- Brouillon
- Diffusion
- Archives

Chacun possède l'arborescence complète de mon site...

Le répertoire "Brouillon" contient la version sur laquelle je travaille...
Le répertoire "Diffusion" est une réplique de la version en ligne à laquelle je ne touche pas...
Le répertoire "Archives" regroupe tous les anciens fichiers que je prends soin de dater au moment de l'archivage...

Bob (MC Melun) a écrit :


PHP n'est pas dans le coup !

Il y aura un seul et même PHP pour tous tes sites, quelle que soit l'arborescence mise en place...

Ha ! Voilà ce que je voulais savoir !


Concernant le démarage du localhost, si je comprends bien, c'est en créant un sous-domaine qu'on peut affecter le répertoire racine de son choix... c'est cela les alias, non ?

Bon, à vérifier ...

Merci pour votre aide

Bob (MC Melun) a écrit :


PHP n'est pas dans le coup !

Il y aura un seul et même PHP pour tous tes sites, quelle que soit l'arborescence mise en place...

Php sera t-il toujours le même, l'herbegeur autorisera t-il les mêmes fonctionnalités chez lui qu'à la "maison", Apache est-il configuré de la même manière, MySql est peut-être d'une certaine version et n'autorise pas telle ou telle chose alors qu'une version "up to date" l'autorise.

Quand on développe en local avec php et ses amis il faut tenter de se rapprocher de la configuration de son hébergeur en terme de fonctionnalités et... d'interdictions parfois. Il y a parfois des surprises qui à ne pas en tenir compte une fois les ressources mises en ligne risques de ruiner un site.

Un php info sur son hébergeur peut parfois être utile. Au delà de la correspondance des arborescences entre local et l'espace web. Chacun fait bien comme il veut quitte à être bordélique en local si en ligne c'est bien rangé . La configuration du serveur est rarement négociable.

<? phpinfo(); ?>