Message d'avertissement

The subscription service is currently unavailable. Please try again later.

organisation d'une installation

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,

Petite demande de conseil en organisation.

Je travail en ce moment sur la conception d'un projet global qui comprend plusieurs services bien distinct n'ayant pas ou peu de relations entre eux.

Et je m'interroge sur la meilleur façon d'organiser le projet. Selon vous, est ce que j'aurais intérêt à :

  • faire un seul site pour tous les services.
  • faire autant de site que de services (des services, il y en aura de plus en plus dans le futur
    • De mon point de vue, la seconde solution est la meilleur. Je pourrais pour l'instant organiser ça comme ceci :
      • introduction.mondomaine.fr/fr . introduction.mondomaine.fr/en
      • service1.mondomaine.fr/fr . service1.mondomaine.fr/en
      • service2.mondomaine.fr/fr . service2.mondomaine.fr/en
      • acces_pro.mondomaine.fr
      • blog.mondomaine.fr
      Le problème, c'est qu'à présent, je ne sais pas faire communiquer les site entre eux. Entre les services 1 et 2, les utilisateurs doivent pouvoir utiliser les mêmes login et mot de passe. Et ils doivent pouvoir s'inscrire depuis introduction, service 1 et 2. Des suggestions ? Merci. Cordialement Michael

Oui bien sure drupal a tout prevu.lol.

Tu te sert du multi site drupal et tu ajoute le module SSO.Il te permet le partage des user et meme mieu kan tu te connecte a l un d entre eu tu est connecte a tout les autres

il n y a pas tant de faute d orthographe que ca et puis c est parfaitement comprehensible ce ke j ai ecrit.Ici il faut etre simple et rapide et essayer d aider les autres et se faire aider.Il n est pas utile de perdre son temps a juger les autres comme tu le fait.Ca n avance pas comme ca les pb.

Ce n'est pas toi, c'est ton style que je juge. On n'est pas sur un tchat d'ados et respecter l'orthographe, c'est respecter ceux qui vont lire. Une réponse précipitée est moins utile qu'une réponse pertinente, elle peut même faire perdre beaucoup de temps. C'est tout.

pour ta gouverne ma réponse n etait pas precipité.Et en plus elle est pertinante.J ai tort dans ce ke je met dans ma réponse.Non mais tu est grave kan meme.

Et ya des ado qui font du drupal.Tu va leur interdire de parler??

A bon entendeur salut

Il y a plusieurs solutions, il faut que tu les testes pour voir celle qui correspond le mieux à ton besoin. Il y a Domain Access par exemple ; mais tout dépend des liens entre sites, si vraiment il n'y en a pas beaucoup (de liens), plusieurs sites distincts sont sans doute préférables. Pour le partage des utilisateurs et la connexion liée, il n'y a pas besoin d'un module il suffit de mettre un peu les mains dans le cambouis (et dans la doc anglaise) : une des tables de la base peut très bien être commune à plusieurs sites et on paramètre le cookie pour conserver la connexion d'un site à l'autre. Sur le site anglais, tape des sujets de recherche comme "share users" ou "share sign-on".

Salut Marie-Hélène,

Merci beaucoup de ta réponse. Domain access et ton idée de partage de tables me paraissent être des solutions intéressantes. A tester et évaluer pour mesurer les pour et les contres.

Pour les avantages je vois en ce moment :

  • Une meilleure structure pour un projet qui pourrait finir par contenir une multitude de services différents. (la super galère si c'est sur une seule install).
  • Chaque service peut avoir un thème spécifique (bien que ce soit possible aussi en partant sur une base commune à chaque service)
  • Certains aspects du projet son externalisés. C'est le cas d'applications mobiles. Avoir un espace dédié pour chaque service me paraît plus pratique pour un travail à plusieurs.

Pour les inconvénients :

  • Devoir mettre les mains dans le cambouis comme tu le dis. Ayant conciense que je n'ai pas toujours connu beaucoup de chance quand j'essaye de demander à Drupal autre chose que ce qu'il sait faire (et qu'il fait très bien d'ailleurs).

A noter que dans leur profil, les utilisateurs auront une série d'onglets sous lesquels ils pourront paramétrer leurs données personnelles relatives à chacun des services (visualisation du nombre de points, modification des propriétés propres à chaque service). -> C'est à ce niveau qu'une telle organisation risque de poser le plus de problèmes.

Voilà, si vous voyez d'autres avantages/inconvénients, ce serait super sympa de les partager.

Merci beaucoup.

Bon week-end

Si vraiment tu veut pas te prendre la tete.Utilise le module section.Ainsi tu partage toutes tes données sauf le theme.Tu passe d un site a un autre grace a section en swichant de theme.si tu a le meme nom de domaine pour tes site, c est la chose la plus simple à faire

Il me semble à lire ton problème qu'il vaudrait mieux partir sur un simple partage de la table users, pas plus, tout le reste étant distinct par site, pour préserver l'intégrité de chaque site. Mais cela implique que tu ne puisses pas afficher dans un site le contenu des autres sites (je n'ai pas très bien compris si tu avais besoin de cela).

Tu as peut-être vu que tu peux même avoir une base de données séparée pour chaque site et leur faire utiliser une table _users sur une autre base ; il suffit de bien indiquer dans le settings.php quel comportement tu veux, pour la table _users et pour le cookie lié à la connexion. Cela te demande un peu de configuration au départ mais ça me semble la solution la plus appropriée. Teste-la avant de l'adopter définitivement, bien sûr.

N'oublie pas qu'une installation multisite nécessite que tu mettes à jour tous les sites en même temps. Pour avoir testé une solution multisite avec des tables partagées, je n'ai jamais constaté de problème de mise à jour lié au fait qu'une partie des tables soient communes à plusieurs sites (tu lances le script update.php depuis chacun de tes sites, s'il y a une mise à jour à faire sur la table _users Drupal ne la fait qu'une fois et s'accomode très bien de la situation ensuite).

Marie-Hélène, merci encore pour tes réponses pertinentes.

Tu dis :
Mais cela implique que tu ne puisses pas afficher dans un site le contenu des autres sites (je n'ai pas très bien compris si tu avais besoin de cela).

Pour l'instant, je vois des services bien dissociés. Néanmoins, il est très probable à un moment donné qu'il y ai des contenus qui soient remontés d'un service à l'autre, comme des bloques de statistiques etc. Et comme je le disais précédemment, il y a des settings dans le compte utilisateurs, relatifs à chaque service.

En tous les cas merci de l'explication pour le partage de la base "user" je vais tester ça (pas encore eu le temps !)

Bonne fin de week-end.
Et merci encore

J'entends "contenu" au sens drupalien du terme : les noeuds eux-mêmes. Note que ça peut se partager aussi (toutes les tables node*), c'est plus compliqué si tu utilises des types de contenus CCK, mais c'est faisable. Les blocs de statistiques ne sont pas des contenus (une statistique est le résultat d'un calcul) ; je ne sais pas très bien comment tu pourras résoudre cette question là. Concernant les paramètres du compte utilisateur, je ne sais pas ce que tu entends par là mais a priori, la table users de drupal conserve uniquement ce dont drupal a besoin pour les connexions. Si tu as besoin de données personnelles (de profils utilisateurs), elles seront dans une table spécifique (_profile pour le module Profile ou des tables CCK si tu as recours au module Content profile). Pour les paramètres liés à chaque module, en principe (à vérifier) le développeur du module a prévu une table qui, pour chaque UID, conservera les paramètres nécessaires. Il n'y a a priori pas d'obstacle de ce côté là, ça fonctionnera sans problème.

Après, je n'ai pas ton projet sous les yeux donc je ne peux pas te garantir que c'est ce qu'il te faut.

Bon dimanche à toi aussi.

Merci beaucoup,

je pense donc partir pour cette config là. Pour les paramétrages dans le compte perso, c'est des settings du style "afficher tel élément sur la carte dans tel service", afficher ma photo pour le service 1 etc...

Donc de ce côté, il y aura certainement de la communication à faire entre les sites. Je me plongerais dedans au moment venu (cependant, je devrais quand même tester tout ça avant la fin du début de la semaine :p) :D

Je ferais signe quand je serais plus avancé.

Merci et à bientôt

Hello Marie-Hélène,

Pour tester l'utilisation de champs CCK, j'ai installé le multisite pour partager les nodes. Et effectivement, si j'implémente un champs CCK sur un node, il ne s'applique qu'au site depuis lequel j'ai fais la manip.

Si je voulais partager seulement certains types de nodes, es ce que tu penses que celà serait faisable ? Sachant qu'il sont pour l'instant tous dans une seule et même table "node"

Sinon, ça fonctionne vraiment très bien et je voulais te remercier encore.

Quelques docs intéressantes pour ceux intéressé par le "multisite partagé" :
http://drupal.org/node/201673 (doc pour Drupal 5, fonctionne bien aussi pour Drupal6)
http://groups.drupal.org/node/4247 (liste de tables)

Bonne journée à tous.

Le partage de contenus utilisant CCK est compliqué dans D6 parce que les données ne sont pas au même endroit (le CCK a ses tables à lui) ; si tu définis un comportement par défaut "aucune table partagées sauf users et les tables x, y et z à un moment donné", tout champ que tu vas créer après sera spécifique à chaque site. Donc soit tu crées tous tes types de contenus et champs et tu peux partager toutes les tables CCK et node pour un contenu totalement partagé, mais il ne faut pas avoir à y revenir ensuite, soit tu n'essaies pas de partager le contenu. Ou alors, dès que tu crées un champ supplémentaire il faut ajouter la table correspondante aux tables partagées dans le settings, c'est pas très simple.

Je t'ai dit que pour partager le contenu, le préfixage des tables n'est pas une solution très simple à mettre en oeuvre.

Par ailleurs j'avais fait ce genre de tests il y a longtemps (un an), et jamais en prod. Donc c'est sous toutes réserves.

Merci Marie-Hélène,

Comme tu le dis, ce n'est pas très simple. Je me suis rabattu sur un site commun : Moins propre, mais beaucoup plus rapide et facile !

Ceci dit, les tests que j'ai réalisés m'ont vraiment permis de plonger le nez dans la bdd de drupal.

Donc merci beaucoup pour ton aide.

Oui, c'est un bon exercice, quoiqu'un peu frustrant. Sauf erreur de ma part, ce devrait être plus facile dans Drupal 7 car

  • tous les champs sont traités de la même manière (pas de distinction entre titre-et-body et les autres champs)

  • il y a une table avec les paramètres de chaque type de contenu (les champs qu'il faut) et une table par champ avec les données (je crois même qu'il y a deux tables par champ)

Donc on peut partager la table des paramètres (donc avoir des types de contenus identiques dans chaque site) mais préfixer les tables des données (donc un contenu bien distinct par site).