web-dev-qa-db-fra.com

Comment implémenter WordPress dans un sous-répertoire, hébergé sur un serveur différent?

Je travaille avec un client qui a déjà un site Web de commerce électronique personnalisé configuré dans son propre domaine, par exemple. exemple.com

Nous souhaitons héberger leur blog WordPress dans un sous-répertoire de leur domaine, par exemple. example.com/blog En raison de problèmes de sécurité, nous ne pouvons pas héberger WordPress sur le même serveur que le reste de leur site.

Nous avons mis en place un serveur distinct qui hébergera le blog WordPress et lui donnera une URL de sous-domaine temporaire.

Comment pouvons-nous faire en sorte que example.com/blog serve le site Wordpress à partir de notre serveur? Nous ne voulons pas d'une redirection, nous voulons qu'elle apparaisse comme si tout le blog était hébergé dans le sous-répertoire '/ blog'. Quelles URLs mettons-nous dans la base de données WordPress? Comment devraient-ils rediriger leur sous-répertoire?

Je sais que les gens recommandent l’utilisation d’un sous-domaine (c’est ce que nous avons actuellement), mais le client a spécifiquement demandé l’utilisation d’un sous-répertoire pour de meilleures performances de référencement.

wordpressredirectsserversubdomainsubdirectory
3
J. Purcell

Le sous-domaine est certainement l'option la plus simple puisque vous souhaitez héberger le site sur un autre serveur. La raison en est qu'un nom d'hôte ne peut jamais être résolu en un seul emplacement. Si vous êtes préoccupé par le référencement des URL modifiées, vous pouvez éventuellement envisager une redirection vers le sous-domaine.

Cependant, puisque vous cherchez spécifiquement à éviter le sous-domaine, le reste de cette réponse portera sur la façon de le faire.

Si vous voulez que/blog/soit servi depuis un autre serveur, vous devez créer un proxy inverse. En fonction de votre niveau d'accès au serveur Web actuel, la meilleure option serait de créer un proxy inverse. Les instructions suivantes peuvent nécessiter une certaine habileté avec les modifications du serveur à implémenter et à résoudre les problèmes.

Utiliser Apache

En supposant que vous utilisez Apache, vous pouvez ajouter une règle comme celle-ci:

ProxyPass /blog/ http://example.com/blog
ProxyPassReverse /blog/ http://example.com/blog

Vous pouvez placer ceci dans votre entrée VirtualHost ou quelque part dans votre httpd.conf. Cela suppose que vous avez installé mod_proxy et qu'il vous faudra redémarrer Apache.

Si vous utilisez cPanel, ce qui est populaire, vous pouvez rechercher ici des emplacements pour placer un fichier dont le nom se termine par .conf: https://documentation.cpanel.net/display/EA/Modify + Virtualhost + Containers + With + Include + Files

Si vous utilisez cPanel, mod_proxy devrait être inclus. Vous ne devriez donc pas avoir à vous soucier de cela, mais vous aurez besoin de /scripts/rebuildhttpdconf, puis de redémarrer Apache.

Cela vous permettrait d'établir une connexion vers un autre emplacement afin de récupérer les pages de blog à diffuser via votre serveur actuel.

Le problème avec WordPress, comme de nombreux CMS, est qu’il est très difficile de choisir l’URL que vous utilisez pour y accéder. Cela signifie que si vous vous connectiez à un sous-domaine, si le siteurl ne correspondait pas, WordPress servirait un serveur 404. De plus, WordPress afficherait souvent des redirections contenant le siteurl. . Par conséquent, vous devrez probablement faire croire au serveur que vous vous connectez à la même URL, même si vous vous connectez à un serveur distant. La difficulté réside dans le fait que vous aurez également besoin d’un accès root pour pouvoir modifier le fichier hosts de votre serveur. Sur un serveur Linux, vous trouverez cela à /etc/hosts/, et vous pouvez ajouter une ligne comme celle-ci:

123.123.123.123 example.com

Où 123.123.123.123 serait l'adresse IP du serveur sur lequel vous hébergeriez le blog. Bien entendu, cela ne fonctionnera que si personne d'autre sur ce serveur ne s'attend à se connecter à example.com.

Utiliser Nginx

Si vous utilisez Nginx, ce qui est un peu moins courant, vous pouvez le faire un peu plus facilement:

upstream blogbackend {
    server 123.123.123.123:80;
}

location /blog {
    proxy_pass http://blogbackend;
}

Comme Nginx vous permet de spécifier une adresse IP pour le backend, vous ne devriez pas avoir à jouer avec le fichier hosts.

URL du site

Dans les deux cas, le serveur distant sur lequel se trouve le blog doit être configuré pour servir le contenu de http://example.com/blog, et ce sera le option_value pour siteurl et home dans le $ prefixoptions table. Si c'est l'URL d'origine, vous ne devriez pas avoir à le changer. Si vous devez effectuer des modifications, préparez-vous à vérifier les URL codées en dur, telles que les images téléchargées, etc.

Conclusion

Cette solution est un peu compliquée et beaucoup de problèmes peuvent survenir. Cependant, il reste probablement plus propre que l'alternative suivante, où vous avez/blog/diffusez du contenu via un proxy PHP, éventuellement en utilisant curl. C'est la raison pour laquelle l'approche standard serait simplement d'utiliser un sous-domaine.

3
DKing

Votre serveur a une adresse IP, vous pouvez donc simplement la saisir, puis créer un sous-domaine où le DNS du domaine est hébergé. Supposons donc que vous souhaitiez créer blog.domain.com, vous pouvez l'indiquer à l'adresse IP de vos serveurs.

0
Dynadot