Quand dois-je utiliser une configuration multi-sites?


13

J'ai 4 sites Drupal qui n'ont rien à voir entre eux, sauf qu'ils fonctionnent tous sur Drupal et qu'ils sont tous gérés par moi.

Les modules dont chaque site a besoin varient, mais ils partagent probablement un petit sous-ensemble de modules.

Cette situation est-elle un bon candidat pour utiliser la configuration multi-sites?

Et si je veux ajouter un cinquième site? Comment puis-je télécharger le nouveau, ou comment cela fonctionnerait-il?

Réponses:


11

Les configurations multi-sites sont un peu délicates en raison de leur dépendance à la même base de code. Vous pouvez utiliser une configuration multi-sites dans ce scénario, mais gardez à l'esprit que lorsque vous mettez à niveau un module dans sites/all/modules, cela affectera tous les sites (sauf si remplacé sites/$SITENAME/modules).

Cela conduit à des problèmes potentiels lorsqu'un de vos sites s'appuie sur la version N d'un module, mais que vous souhaitez utiliser N + 1 sur un autre site. Le module en question pourrait ne pas avoir de chemin de mise à niveau, ou il pourrait avoir radicalement changé sa fonctionnalité entre les versions (pas aussi rare que vous pourriez le penser, étant donné la culture Drupal vers les versions principales).

De plus, si des modifications critiques de la base de données sont nécessaires lors d'une mise à niveau du module, vous constaterez que vous devez supprimer plusieurs sites en même temps pour vous assurer que vous exécutez update.php.

Donc, pour la plupart des cas d'utilisation, le multisite n'est pas la solution. À moins que vous ne soyez vraiment à court d'espace ou que vous ayez une restriction d'hébergement étrange qui vous empêche de mapper le domaine de chaque site dans un dossier séparé, vous feriez probablement mieux de maintenir des bases de code distinctes et d'utiliser des outils comme Drush et le contrôle de version pour accélérer le code déploiement.

Le cas d'utilisation prototypique du multisite, en dehors de son utilisation comme solution de contournement pour les hôtes restrictifs, est lorsque vous déployez une tonne de sites extrêmement similaires. Vous pourriez être en train d'exécuter un service d'hébergement, ou de créer un tas de micro-sites pour une entreprise, ou quoi de plus. Dans ces cas, vous pouvez rouler votre propre configuration multisite, mais vous devriez également envisager d'utiliser Aegir , qui automatise et résume beaucoup de tracas liés à l'exécution d'une telle configuration.

L'ajout de nouveaux sites à une configuration multi-sites est assez simple: créez un nouveau dossier sous sites, modifiez sites/sites.php(Drupal 7 uniquement), copiez- sites/default/default.settings.phple settings.phpdans ce nouveau dossier et visitez le site dans un navigateur. Drupal devrait commencer le processus d'installation et utiliser le nouveau dossier. Votre nouveau site aura accès à tous les modules sous, sites/all/modulestout comme vos sites sortants.


C'est plutôt cool. C'est en fait en quelque sorte lié à mon autre question sur les liens symboliques et le dossier des modules. Je suis fatigué d'avoir à répéter la même routine chaque fois que je démarre un nouveau site de test sur mon environnement de développement, et je suis aussi assez malade de copier des modules (en particulier des modules personnalisés) sur plusieurs projets (complique la mise à jour). Je suppose donc que je pourrais utiliser l'approche multi-sites, au moins pendant le développement.
sameold

@sameold ce que j'utilise pour le développement Drupal est un référentiel git qui contient mes modules indispensables en tant que sous-modules. Ensuite, il suffit de courir git clone git@my.repository.com:/base.git newsitepour obtenir un environnement propre.

4
Une alternative serait un fichier de création drush pour la configuration de base. Une autre note mineure, la modification de sites / sites.php est facultative et n'est nécessaire que lorsque la recherche par défaut comme dans D6 ne fonctionne pas (par exemple, multi-sites avec plusieurs domaines pour un seul site).
Berdir

2

J'utiliserais un site multi où vous avez une offre de contenu connexe mais pour différents publics.

Par exemple, nous l'utilisons pour notre intranet qui prend en charge plusieurs marques. Cela permet à chaque marque d'être administrée individuellement avec une option de partage de contenu / utilisateurs (gain de temps énorme sur la réduction de la duplication).

Le fait d'avoir une interface unique (menus / blocs / thématiques) contribue grandement à garantir que les différents services peuvent facilement accéder à ce qui est le plus important pour eux.

De nombreuses fonctionnalités sont disponibles à l'aide de l' accès au domaine, telles que permettre à un utilisateur de définir son site par défaut, différents sites par sous-domaine (vous pouvez donc avoir marketing.intranet.local ou engineering.intranet.local, etc.), rechercher entre les sites, contrôler l'accès, etc. .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.