Besoin d'aide ?

2 sites quasi identiques - 2 domaines - 2 bases de données - 1 seul projet ?

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Bonjour tout le monde !

    Je dois créer deux sites quasi identiques, les choses qui changent sont :

    • Les couleurs, le logo, le titre (mais même template)
    • Le produit vendu (je reste discret mais on peut prendre comme exemple site1.fr qui vend des formations, et site2.fr qui vend des concours). Ici on a deux modèles différents avec des champs différents évidemment. Mais tous les autres modèles auxquels sont attachés ces formations et concours sont identiques ou presque : User, Reservation, Paiement, Facture, Centre_de_Formation/Concours, et ainsi de suite.
    • Le contenu et la fréquence des mails et sms
    • Les infos demandées au client lors de son inscription même si une partie importante sera commune.
    • Peut-être d'autres que j'oublie mais on ne doit pas en être loin.

    Je souhaite avoir deux noms de domaines (et pas sous-domaines).

    Je n'ai pas besoin d'utiliser une base de données commune. (Cela m'ajouterait plus de travail pour séparer artificiellement les données de chaque site, je pense.)

    Je souhaites tant que possible éviter de faire tout deux fois.

    J'ai regardé un peu le sujet, il semble y avoir plusieurs solutions :

    • La solution multi domaines, 1 seul projet, mais ça ne me convient pas car je souhaiterais séparer en deux bdd
    • La solution deux projets distincts et des "sous-modules git" pour pouvoir cloner des parties du projet a dans le projet b... ça me parait vraiment compliqué à mettre en place.
    • La solution à laquelle j'ai pensé, mais qui peut-être une mauvaise idée : Un seul et unique projet cloné sur a et b, avec des if un peu partout pour savoir si on execute le code du site a ou celui du site b. Cela implique évidemment un projet plus important, plus difficile à lire et à maintenir. Mais je pense que je nombre de lignes supplémentaires est négligeable.

    Ca vous parle comme solution ? Parceque j'ai comme l'impression que c'est un peu bourrin...

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1998

    Salut,

    Pourquoi pas créer un package pour tout ce qui est commun ?

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Salut bestmomo, je n'avais pas pensé à cette option... et je vois assez mal comment faire, si on parle de plus de la moitié du code qui serait contenue dans un package...

    Cela ne va pas m'obliger à réecrire ce que j'ai déjà fait ?

    Tu aurais un exemple rapide ?

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1998

    Salut,

    Ce que tu as écrit tu peux très bien le transférer dans un package, on peut y mettre tout ce qu'on veut : routes, contrôleurs, configurations, vues...

    Si tu n'es pas familiarisé avec les packages ce ne sont pas les exemples qui manquent.

    Une autre approche peut être modulaire.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Ok, merci. Au niveau de git, comment ça se passe ? J'imagine que le dossier du package va se retrouver dans /vendor/, qui est dans .gitignore. Je dois donc pouvoir faire un nouveau repository pour ce sous-dossier ? Et ensuite on s'en sert juste en local, et en ligne tout se fait via composer pour importer dans chaque site, c'est bien ça ?

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1998

    Oui tu créés un dépôt que tu installes avec Composer.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Je pense que je ne vais pas faire comme ça en fait, trop compliqué pour moi, et ça m'oblige à rendre public mon code si je ne veux pas faire du copier-coller tous les jours, ce qui est impossible dans ce projet.

    Est-ce-que ce type d'approche est envisageable selon toi :

    A chaque fois que l'on rencontre un modèle, Formation ou Concours, au lieu d'y faire référence directement, par exemple Formation::where('truc', 'chose')->get();, on appelle une variable qu'on pourrait stocker dans .env par ex. $model->where('truc', 'chose')->get();

    Un peu comme le fait Voyager dans son système BREAD (que j'utilise dans ce projet d'ailleurs)... C'est à chaque fois le même controlleur et les mêmes vues quel que soit le modèle.

    Ca me semble un peu plus simple à mettre en place... mais je ne me rend peut-être pas compte.

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    Je souhaite avoir deux noms de domaines (et pas sous-domaines).

    Tu peux très bien gérer 500 NDD avec le même code, il suffit de faire pointer tes DNS vers ton serveur et de faire pointer tes "DocumentRoot" (au sens large, apache ou nginx) vers le même répertoire.

    Je n'ai pas besoin d'utiliser une base de données commune. (Cela m'ajouterait plus de travail pour séparer artificiellement les données de chaque site, je pense.)

    Ca va surtout t'ajouter du travail à chaque fois que tu devras migrer tes BDD. Puis ça commence avec 2, ensuite 3, etc...

    Je souhaites tant que possible éviter de faire tout deux fois.

    Avoir 2 bases avec la même structure c'est faire les choses en double

    La solution multi domaines, 1 seul projet, mais ça ne me convient pas car je souhaiterais séparer en deux bdd

    Un projet peut gérer plusieurs BDD heureusement, les connexions sont là pour ça...

    La solution à laquelle j'ai pensé, mais qui peut-être une mauvaise idée : Un seul et unique projet cloné sur a et b, avec des if un peu partout pour savoir si on execute le code du site a ou celui du site b. Cela implique évidemment un projet plus important, plus difficile à lire et à maintenir. Mais je pense que je nombre de lignes supplémentaires est négligeable.

    En objet on colle pas des if "un peu partout", on utilise le polymorphisme...

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Merci F.M. (ainsi que pour ta réponse sur mon autre sujet).

    Donc si je résume tout ça, je finis avec un seul projet, un seul hébergement, une seule base, et un système à la Voyager (polymorphique donc). :)

    Merci à tous les deux de m'avoir éclairé !

  • Avatar de bdfi
    Membre depuis :
    02/03/2014
    Messages :
    69

    @Charlie_Web_Nancy
    Juste une petite note : si tu souhaites deux sites complètement distincts qui ne se croiseront pas ("musique classique" et un autre "musique métal" par exemple) et qu'en plus il est bien possible que à terme tu veuilles "donner" ou "déléguer" un des deux sites, qui sera alors géré par une équipe d'aministration totalement distincte, mon avis est qu'il vaut mieux deux bases distinctes...

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    @Charlie Y'a pas forcément de réponse toute faite. Ce que j'essaie de t'expliquer c'est qu'il ne faut pas choisir en fonction de mauvais critères.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Oui merci F.M. j'avais bien compris ! Mais justement en fonction de mon projet, et de sa potentielle évolution, ainsi que du fait que je sois seul sans équipe (ce qui simplifie pas mal le tout), je pense que le plus judicieux sera cette solution. Les deux sites sont et resteront totalement liés, donc une seule base me semble être plus simple après réfléxion. Surtout que je viens de me rendre compte que Voyager ne créait pas de migrations lors des modifs en bdd donc ça implique beaucoup de travail sur les bases de données pour faire correspondre un site et l'autre... Si je divise leur nombre par deux, ça devrait me simplifier grandement la tâche.

    Il faut encore que je trouve comment implémenter correctement le multi-domaines et le polymorphisme qui en découle, mais ça m'a permis de faire mon choix.

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    Bon courage dans ton nouveau projet. Si t'as besoin d'avis sur la façon de mettre en place le polymorphisme, je te donnerai le mien.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    64

    Merci, oui ça m'intéresse, je ne me suis pas encore penché sur la question, mais je vais devoir le faire ces-jours-ci...

    Tu as quelques tuyaux/recommandations sur une façon simple de faire ça étant données les quelques infos que j'ai données à propos de mon projet ? Je peux en dire un peu plus si besoin.

    J'imagine que l'essentiel se fait dans les routes, qu'on divise en deux groupes, site 1 et site 2 (?)

    J'utilise Voyager pour plus de simplicité côté "superadmin" et bdd, et j'ai construit un back office à part pour les "admins simples" (qui seront nombreux). Peut-être que cela va me poser des problèmes au niveau du multi-domaines (je pense surtout à Voyager).

Vous ne pouvez pas répondre à ce sujet.