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

4

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?

    
posée David 23.10.2017 - 13:29

1 réponse

4

Du point de vue de l'utilisateur, il existe 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 d’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 lorsque vous modifiez un site déjà créé. Mais cela est possible dans les deux modes.)

L’autre n’est pas évident au premier abord et il 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 existe 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ù ces informations sont stockées. Pendant le processus d'installation, WordPress stocke une valeur entière en tant que méta du 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 site meta 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 la 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.

L'ensemble de règles de réécriture suggéré par défaut pour le mode de sous-répertoire est donc 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 le mode sous-domaine est suggéré comme suit:

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 strongment 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 is_subdomain_install() API

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éfini et défini sur 'yes'

Il renvoie false si SUBDOMAIN_INSTALL est défini et défini sur false . Et il retourne tout le reste si SUBDOMAIN_INSTALL est défini mais pas de type boolean. La méta-valeur du site mentionnée ci-dessus est uniquement utilisée lors du processus d'installation de plusieurs listes. 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 en 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, cela devrait être fait via un petit script PHP qui peut ê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 en 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 blog slug 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 qui utilise 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 la plus grande souplesse possible. 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).

    
réponse donnée David 23.10.2017 - 13:29

Lire d'autres questions sur les étiquettes