Les blogs d'un multisite peuvent-ils être accessibles à partir de deux sous-domaines différents?
Contexte rapide:
Nous avons une seule instance WordPress, avec Multisite activé, hébergeant trois blogs distincts. (blog.example.com/blog1, blog.example.com/blog2, blog.example.com/blog3).
La charge de ce multisite sera équilibrée sur un serveur Web de quatre serveurs accédant tous à la même base de données. Je comprends que blogs.dir devra être synchronisé sur le niveau Web pour que les médias soient présents, quel que soit le serveur sur lequel un client se connecte.
Question:
Puis-je avoir un cinquième serveur Web (c'est-à-dire, post.example.com), dont le seul but est de permettre aux éditeurs de se connecter et de publier un nouveau contenu, pour l'un des trois blogs? De cette façon, les serveurs à charge équilibrée ne sont que les destinataires du contenu téléchargé à partir de post.example.com.
Je sais que la synchronisation est possible, mais je ne suis pas sûr de savoir comment configurer WordPress pour qu'il soit accessible à partir de deux sous-domaines différents. Est-ce possible?
Edit: J'ajouterais qu'un objectif supplémentaire, en le configurant de cette manière, est que nous espérons gagner un peu de sécurité grâce à l'obscurité, en bloquant l'accès à /wp-admin/ sur la couche Web, vous ne pouvez donc vous connecter qu’à partir du serveur Web unique (post), mais cela dépend évidemment de la question susmentionnée. :)
Mock ci-dessous:
Oui, cela est possible et un certain nombre d'agences de presse et de médias utilisent des approches similaires dans WordPress.
Quel est votre processus éditorial?
L’étape la plus importante est la compréhension de votre processus éditorial et du contrôle que vous devez avoir sur le contenu avant sa mise en ligne.
- par exemple, considérons ces 3 points:
1. Avez-vous besoin d'approbations tierces pour les images?
2. Est-ce que vous ou votre client devez signer copie/images/vidéo/mise en page avant que le contenu ne soit publié?
3. Est-ce que les rédacteurs travaillent sur différentes semaines ou questions et prévoient que leur contenu sera mis en ligne des semaines à l'avance ...
Si vous avez répondu oui à l'une de ces questions, il est alors impossible de créer une seule base de données partagée entre votre serveur Pre-Live/Staging et votre serveur Live. Pourquoi demandes-tu? car une nouvelle publication doit être publiée avant de pouvoir être visionnée par des non-utilisateurs ou des tiers à qui vous ne souhaitez pas attribuer de noms de connexion également. (BTW ... tout est possible avec du temps, de l'argent et des compétences pour personnaliser les rôles et les niveaux d'accès des utilisateurs).
Revenons donc à la solution évolutive de WordPress
DOMAINE A (à quoi vont vos clients et visiteurs) devra être dirigé vers un équilibreur de charge HTTP.
L'équilibreur de charge dirigera le trafic client vers l'un des serveurs Web. Ces serveurs esclaves sont conservés dans LSYNC avec un serveur MASTER.
Idéalement, il devrait y avoir 2 serveurs de base de données distincts (pour les demandes de lecture/écriture avec équilibrage de charge et la mise à l'échelle). Vous pouvez vous attendre à beaucoup de trafic de lecture en provenance des visiteurs, mais vous voulez vous assurer que le trafic en écriture de nouvelles publications, etc. n'interrompt pas vos demandes de lecture.
DOMAINE A peut également être dirigé vers un équilibreur de charge HTTPS configuré pour
1. 2. Autorisez uniquement le trafic depuis votre adresse IP Office et 2. Forcer la connexion SSL pour Admin/Connexion.
Il s’agit d’une modification facile du fichier wp-config.php.
Voici un schéma de ce que nous avons construit (avec un peu de support de Rackspace) 
HyperDB
À la fin, nous avons installé HyperDB pour gérer les multiples serveurs et demandes de base de données. C'était aussi facile car il s'agit principalement d'un plugin avec un long script de configuration.
Cache total W3TC W3
Nous avons également reçu les configurations HyperDB et W3TC .. cela a également demandé beaucoup de travail aux serveurs de base de données.
La principale raison pour laquelle nous avons utilisé W3TC était de supprimer tout le contenu statique dans Rackspace. La configuration du réseau de distribution de contenu dans le W3TC est également très simple :)