web-dev-qa-db-fra.com

Multisite: différences entre le mode sous-domaine et sous-répertoire? Peut-il être commuté après l'installation?

La fonctionnalité multisite de WordPress offre deux modes d'installation différents: sous-domaine et sous-répertoire install. Par défaut, les deux modes permettent de gérer des instances (sites) WordPress distinctes au sein d'une installation et d'un domaine principal. La différence évidente est le schéma d'URL pour tous les sites (dans l'exemple, multisite.tld est le doman principal):

  • http://site1.multisite.tld pour l'installation du sous-domaine et
  • http://multisite.tld/site1 pour l'installation du sous-répertoire.

Puisqu'il est possible de mapper n'importe quel domaine arbitraire sur des sites après leur création dans les deux modes, je me demande quelles sont les différences réelles entre les deux? De même, existe-t-il un moyen de changer de mode après l'installation?

multisitedirectorysubdomains
4
David

Du point de vue de l'utilisateur, il y a deux différences notables. Tout d'abord l'interface graphique pour la création de nouveaux sites. Soit il affiche un champ de saisie pour le premier segment du chemin de l’URL (sous-répertoire) ou un champ de saisie pour le sous-domaine que vous souhaitez utiliser pour le nouveau site. (Définir l'URL sur une valeur complètement arbitraire n'est possible que lors de la modification d'un site déjà créé. Mais cela est possible dans les deux modes.)

L’autre n’est pas évident au premier abord et n’affecte que le mode sous-répertoire: la structure de liens permanents des sites principaux aura un préfixe statique blog/ qui ne doit pas être modifié. (Même s'il peut y avoir des solutions, changez ou supprimez le préfixe).

D'un point de vue technique, il s'agit d'une configuration système différente définie par les constantes de configuration, les valeurs de configuration dans la base de données et la configuration du serveur Web. Ce qui définit le mode en premier lieu, c’est la constante IS_SUBDOMAIN_INSTALL qui peut être définie sur true (mode sous-domaine) ou false (mode sous-répertoire). Mais ce n'est pas le seul endroit où cette information est stockée. Pendant le processus d'installation, WordPress stocke une valeur entière sous forme de méta de site à l'aide de la clé subdomain_install. Il peut être lu (ou mis à jour) via WP-CLI:

$ wp site option get subdomain_install
1

Le mode sous-répertoire génère un élément supplémentaire dans la liste des slugs de sites interdits: blog. Ces listes sont stockées dans le méta site illegal_names. Ainsi, en mode sous-répertoire, cela ressemble à ceci par défaut:

$ wp site option get illegal_names
array (
      0 => 'www',
      1 => 'web',
      2 => 'root',
      3 => 'admin',
      4 => 'main',
      5 => 'invite',
      6 => 'administrator',
      7 => 'files',
      8 => 'blog',
)

Configuration de réécriture Apache

Le serveur Web n'étant pas responsable des éléments internes de WordPress, sa configuration consiste essentiellement à acheminer l'URL demandée vers le script ou le fichier d'actif approprié. Il s'agit principalement de savoir si les URL de requête telles que /site-slug/wp-[admin|content|includes] et /site-slug/wp-*.php doivent être routées vers les répertoires appropriés (/wp-*/) ou les scripts.

Donc, le jeu de règles de réécriture suggéré par défaut pour le mode sous-répertoire est le suivant:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Alors que l’ensemble pour sous-domaine mode est suggéré comme ceci:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

Le type de jeu de règles utilisé dépend fortement du schéma de domaine souhaité que vous planifiez pour votre site multisite. Le plus flexible est bien sûr le premier (sous-répertoire) car le segment de chemin d’URL ("sous-répertoire") est totalement facultatif}.

Sunrising (routage WordPress) et fonction API is_subdomain_install()

Pour savoir quel mode est configuré, WordPress fournit la fonction is_subdomain_install(), qui renvoie true si:

  • la constante SUBDOMAIN_INSTALL est définie et définie sur true ou
  • la constante SUBDOMAIN_INSTALL n'est pas définie mais VHOST est définie et définie à 'yes'

Il renvoie false si SUBDOMAIN_INSTALL est défini et défini sur false. Et il renvoie n'importe quoi d'autre si SUBDOMAIN_INSTALL est défini mais pas de type boolean. La méta valeur du site mentionnée ci-dessus n'est utilisée que pendant le processus de configuration de plusieurs sites. Le noyau WordPress ne repose que sur la valeur de cette constante partout ailleurs.

Cependant, la valeur de is_subdomain_install() affecte le routage de l'URL demandée vers un site spécifique du réseau uniquement si les constantes DOMAIN_CURRENT_SITE et PATH_CURRENT_SITE ne sont pas définies. (Voir ms_load_current_site_and_network()). Cela signifie qu'il est possible d'utiliser n'importe quel domaine en tant qu'URL de site dans les deux modes (mappage de domaine).

Changement de mode après la configuration

Basculement du formulaire sous-domaine en mode sous-répertoire

  • Modifiez la valeur de la constante IS_SUBDOMAIN_INSTALL de true à false

  • Définissez la valeur de la méta de site subdomain_install sur 0:

    $wp site option set subdomain_install 0

  • Ajoutez le préfixe /blog/ à la structure de lien permanent du site principal. Il sera corrigé après la mise à jour du paramètre.
  • Ajoutez blog à la liste des slugs de sites interdits. Comme cette liste est une valeur sérialisée, vous devez le faire via un petit script PHP pouvant être exécuté via WP-CLI:

$ wp eval-file patch-forbidden-slugs.php

// patch-forbidden-slugs.php
<?php
$illegalNames = get_metadata( 'site', SITE_ID_CURRENT_SITE, 'illegal_names', true );
$blogSlug = 'blog';
if ( in_array( $blogSlug, $illegalNames ) ) {
    exit( 'Noting to do' . PHP_EOL );
}
$illegalNames[] = $blogSlug;
update_metadata( 'site', SITE_ID_CURRENT_SITE, 'illegal_names', $illegalNames );
exit( 'Done' . PHP_EOL );

Basculement du sous-répertoire du formulaire en mode sous-domaine

  • Modifiez la valeur de la constante IS_SUBDOMAIN_INSTALL de false à true

  • Définissez la valeur de la méta de site subdomain_install sur 1:

    $ wp site option set subdomain_install 1

  • Supprimez le préfixe /blog/ de la structure de lien permanent du site principal

  • Supprimez le slug blog de la liste des noms interdits (adaptez le script ci-dessus en conséquence)

Conclusion

Mes remarques ne prennent en compte qu'une installation propre de WordPress et une installation réseau immédiate. La dernière version de WordPress 4.8 est également prise en compte. Il est possible qu’il y ait des implications lors d’une installation multisite sur un système existant utilisant des plugins ou toute version antérieure de WordPress.

Cependant, ma configuration préférée est le mode sous-domaine avec l'ensemble de règles .htaccess pour les sous-répertoires, car il offre une grande souplesse d'utilisation. Il fonctionne même avec les configurations modernes contrôlées par le compositeur, telles que WPStarter (avec une légère adaptation des règles .htaccess).

4
David