Pouvons-nous utiliser une installation WordPress pour plusieurs bases de données, domaines et répertoires de contenu

10

J'ai vu des questions qui se ressemblent, mais elles ont toutes abouti à plusieurs sites . Pour la maintenabilité, les performances et la sécurité, je ne veux pas utiliser le multisite. Restez avec moi.

Voici à quoi je pense:

.
|_____branch1 // for branch1.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch2 // for branch2.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch3 // for branch3.domain.com
|  |_____themes
|  |_____plugins
|
|_____index.php
|_____WordPress
|_____wp-config.php

Comme vous pouvez le voir, chaque domaine possède sa propre base de données et son propre répertoire de contenu, mais une seule instance WordPress. Désormais, les thèmes, plugins et bases de données deviennent plus petits et indépendants. Il serait alors beaucoup plus facile de maintenir, de mettre à l'échelle ...

Mais est-ce possible? Si vous avez déjà rencontré le même problème, merci de partager vos impressions! J'apprécie vraiment votre aide.

customization multisite SarahCoding
la source
1
Pourquoi le multisite a-t-il été éliminé comme une possibilité? Cela impliquera la création d'un système fragile qui sera moins maintenable que le multisite, aura des performances plus lentes que le multisite et une sécurité moins bonne que le multisite. Certaines des plus grandes installations de WordPress sont des installations multisites, et il s'agit du même code qui s'exécute sur un seul site standard
Tom J Nowell
Je gère plusieurs sites WP multiples, dont un qui compte plus de 500 sous-sites. Les performances seront les mêmes que vous utilisiez une instance multisite ou 500 WP sauf si vous disposez des 500 instances sur des machines virtuelles et des bases de données distinctes. La maintenabilité craint avec le multisite? Essayez de maintenir 500 numéros de sites uniques.
user42826
@TomJNowell Je ne sais pas si cette plus grande installation utilise une seule base de données, mais je pense que cela et cette vidéo pourraient nous amener à une même page. Nous utilisons principalement WordPress pour CRM et la confidentialité des utilisateurs est très importante.
SarahCoding
@ user42826 Actuellement, mon entreprise n'a pas beaucoup de sites. Je ne peux pas non plus convertir le site actuel en multisite et le comparer. Et le matériel et d'autres choses peuvent différer de vous. Je veux donc simplement demander une architecture d'installation optimale dans mon cas. Pour autant que je sache, le multisite fonctionne avec des sous-domaines mais il ne peut pas fonctionner pour différents domaines.
SarahCoding
Le multisite fonctionne avec différents domaines. Nous utilisons un domaine principal, * .domain.com, et quelques autres domaines, www.domain2.com et www.domain3.com. Nous utilisons le plugin de mappage de domaine WP pour accomplir des domaines multiples, mais d'après ce que j'entends, WP core prend désormais en charge le mappage multidomaine de manière native.
user42826

Réponses:

10

Comme l'a dit @ tom-j-nowell dans un commentaire à OP, le multisite peut faciliter cela.

Les performances et la sécurité ne sont pas vraiment un problème pour le multisite (du moins pas plus que pour les installations régulières), mais je suis d'accord que le multisite peut parfois être un problème, car de nombreux plugins (personnalisés ou tiers) peuvent ne pas fonctionner correctement sur plusieurs sites, ou peut-être parce que vous souhaitez garder les utilisateurs de différents sites Web complètement séparés.

Cela dit, ce que vous voulez réaliser n'est pas si difficile.

Ce que vous devez changer entre l'installation est:

  • dossier plugins
  • dossier de thèmes
  • paramètres de la base de données

Ces configurations peuvent être faites en utilisant des constantes danswp-config.php votre seul problème est de savoir comment les changer en fonction de l'URL.

La variable serveur 'SERVER_NAME'devrait fonctionner pour vous, au moins si votre serveur Web est correctement configuré.

Par exemple, vous pouvez créer un dossier nommé /confau même niveau de wp-config.phpfichier et de /WordPressdossier.

Dans ce dossier, vous pouvez ajouter des fichiers:

  • branch1.domain.com.conf
  • branch2.domain.com.conf
  • branch3.domain.com.conf

à l'intérieur de chacun d'eux, vous pouvez faire quelque chose comme

$branch = 'branch1';
$base_dir = dirname( __DIR__) . "/{$branch}";

defined( 'WP_CONTENT_DIR' ) or define( 'WP_CONTENT_DIR', $base_dir );

// be sure WP understand URLs correctly
defined( 'DB_HOME' ) or define( 'DB_HOME', "{$branch}.example.com" );
defined('WP_SITEURL') or define('WP_SITEURL', "{$branch}.example.com/WordPress");

// adjust DB settings  as needed
defined( 'DB_NAME' ) or define( 'DB_NAME', $branch );
defined( 'DB_USER' ) or define( 'DB_USER', $branch );
defined( 'DB_PASSWORD' ) or define( 'DB_PASSWORD', '********' );

unset( $base_dir, $branch );

Cela changera sur chaque fichier de configuration en fonction de la "branche".

Après cela, dans votre unique, wp-config.phpvous pouvez donc quelque chose comme:

$defaults_conf = [
  'WP_CONTENT_DIR' => __DIR__ . '/branch1',
  'DB_HOST'        => 'localhost',
  'DB_NAME'        => 'branch1',
  'DB_USER'        => 'branch1',
  'DB_PASSWORD'    => '********',
];

$host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

if ($host && file_exists(__DIR__."/conf/{$host}.conf")) {
  require __DIR__."/conf/{$host}.conf";
}

array_walk($defaults_conf, function($value, $name) {
   defined($name) or define($name, $value);
});

unset($defaults_conf, $host);

Ce qui se passe ci-dessus est que, sur la base du nom du serveur, vous chargez un fichier de configuration différent (s'il est trouvé) et si le fichier de configuration ne définit aucune configuration par défaut (ou si le fichier n'est pas trouvé), la configuration est définie par défaut.

Une bonne chose est que pour ajouter une nouvelle branche, il vous suffit de créer le dossier de la branche et de fournir un .confnom d'après le nouveau domaine de la branche, et vous avez terminé, il n'y a rien à changer du côté de WP.

La ligne:

 $host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

c'est là que j'obtiens le nom de domaine. Comme première option, j'utilise une variable d'environnement, car il y a des chances que $_SERVER['SERVER_NAME']cela ne fonctionne pas sur un contexte de ligne de commande, comme nous lors de l'utilisation de WP CLI. Dans ces situations, vous pouvez définir une variable d'environnement pour forcer WP à utiliser les paramètres d'une branche spécifique.

Notez que dans les fichiers de configuration spécifiques à une branche, je modifie le WP_CONTENT_DIRet qui définira automatiquement le dossier plugins et thèmes dans les sous-dossiers liés /pluginset de /themesbranche.

Un problème possible ici est si vous souhaitez partager le /uploadsdossier (où les fichiers sont téléchargés).

Par défaut, ce dossier est un sous-dossier du répertoire de contenu, donc en utilisant le flux de travail ci-dessus, ce sera un /uploadssous-dossier de chaque dossier racine de branche.

Si ce n'est pas un problème pour vous, allez-y, sinon la solution la plus simple serait de créer /uploadsdans chaque dossier de branche un lien symbolique vers le vrai dossier de téléchargement que vous souhaitez partager.

gmazzap
la source
Je vous remercie! J'aime vraiment votre idée même si elle $_SERVER['SERVER_NAME']n'est pas fiable . /uploadsdir n'est pas un problème. J'ai également testé avec WP CLI, si nous passons en --urlparamètre pour chaque site, cela fonctionne normalement :)
SarahCoding
1
@Dan J'ai dit dans la réponse: "La variable serveur 'SERVER_NAME' devrait fonctionner pour vous, au moins si votre serveur Web est correctement configuré." Cela signifie que vous devez configurer votre serveur correctement :) En fait, tant que vous configurez server_namedans nginx ou ServerNamedans Apache ou tout ce qui convient à votre serveur Web, $_SERVER['SERVER_NAME']cela fonctionnera. Même si WP CLI peut fonctionner à l'aide de --urlparamètres, d'autres outils de ligne de commande peuvent avoir des problèmes si vous n'utilisez pas la variable d'environnement. WP CLI "se moque" de l'URL de la demande dans un contexte CLI, d'autres commandes ne le feront probablement pas.
gmazzap
1
Bien sûr, je vais m'assurer que SERVER_NAMEc'est bien configuré. À propos de vars env, j'ai utilisé phpdotenv pour le corriger. Actuellement, tout semble bien fonctionner :)
SarahCoding
0

Cela est possible avec un lien symbolique et un peu de planification. J'ai fait un peu de récurage sur le net pour la même chose. Enfin, rassemblez toutes les choses et faites-les fonctionner.

J'ai couru quelques sites Web, ils partagent tous le même dossier de thèmes et de plugins. Les mêmes dossiers fonctionnent pour les sites multisites et uniques. Mais vous devez faire attention à certains plugins qui ne peuvent être que multi / site unique et être excentriques.

J'ai créé un répertoire comme master-tnp / themes et master-tnp / plugins. Créez ensuite un lien symbolique vers votre répertoire wordpress à l'aide de la commande ln -s.

Les pièges se trouvent également dans les configurations de serveur. Assurez-vous que la directive de suivi des liens symboliques est définie sur autoriser.

Si vous souhaitez utiliser une installation WordPress unique, j'ai mis en place un guide détaillé sur la façon dont je l'ai fait sur https://vaish.co/multiple-sites-single-wordpress-directory

Cpyder
la source