#wordpress #nginx #shiny-server
#wordpress #nginx #блестящий сервер
Вопрос:
У меня возникли проблемы с развертыванием WordPress в поддомене, где в основном домене запущено другое приложение (блестящий сервер). Для целей вопроса, my-domain.com
это основной домен, а местоположение, в котором я хотел бы развернуть сайт WordPress, является my-domain.com/blog
. Это текущий файл конфигурации, который у меня есть (в /etc/nginx/sites-available/my-domain.com
с символической ссылкой на сайты с поддержкой):
server {
root /var/www/my-domain.com; # WordPress directory
server_name my-domain.com www.my-domain.com;
index index.html index.htm index.nginx-debian.html index.php;
## Shiny server
location / {
proxy_pass http://MY_IP:SHINY_SERVER_PORT;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
## WordPress subdomain location
location /blog {
try_files $uri $uri/ /index.php$is_args$args;
location ~ /.ht {
deny all;
}
## WordPress restrictions
location = /blog/favicon.ico { log_not_found off; access_log off; }
location = /blog/robots.txt { log_not_found off; access_log off; allow all; }
location ~* .(css|gif|ico|jpeg|jpg|js|png)$ {
expires max;
log_not_found off;
}
}
## Added PHP config locations for MySQL/WP
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}
## SSL configuration added by certbot
# listen [::]:443 ssl ipv6only=on; # commented out as the server is not ipv6
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/my-domain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/my-domain.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.my-domain.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = my-domain.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name my-domain.com www.my-domain.com;
return 404; # managed by Certbot
}
Предыдущая версия этого сайта была только Shiny server, и я довольно хорошо понимаю, что конфигурация работает для запуска только этого приложения в основном домене. Для справки, дополнительные биты были добавлены на основе этого руководства. Приведенная выше конфигурация отлично запускает приложение Shiny server my-domain.com
, но когда я перехожу к my-domain.com/blog
, появляется следующая «сломанная» версия WordPress:
Я также убедился, что правильно настроил WordPress: он работает, если я закомментирую proxy_pass
сквозные proxy_set_header
строки и добавлю try_files
строку в основной location /
блок и удалю location /blog
блок). Я считаю, что моя проблема заключается в неправильном понимании var/www
каталога, отсутствии знаний php и общем любительском понимании Nginx в целом. Что я здесь делаю не так? Этот вопрос, похоже, близок к выполнению того, что я хочу, но после реализации этого my-domain.com/blog
загружает файл php вместо загрузки чего-либо. Пожалуйста, дайте мне знать, если я могу предоставить какую-либо дополнительную информацию — я в недоумении. Спасибо!
Ответ №1:
На случай, если кому-то интересно, я понял это. Я был довольно близок, но некоторые вещи были отключены.
1.) Файлы WordPress были расположены в главном /var/www/my-domain.com
каталоге, но их нужно было переместить в соответствующий подкаталог, который соответствовал расширению, в которое я пытался переместить WordPress. В этом случае: /var/www/my-domain.com/blog
.
2.) После этого конфигурацию Nginx из моего первоначального вопроса необходимо обновить следующим образом:
От:
## WordPress subdomain location
location /blog {
try_files $uri $uri/ /index.php$is_args$args;
Для:
## WordPress subdomain location
location /blog {
try_files $uri $uri/ /blog/index.php$is_args$args;
3.) Кроме того, и я не уверен, имеет ли это значение, но мой исходный корневой каталог был установлен как /var/www/my-domain.com
, и я изменил это на /var/www/my-domain.com/
. Это может вообще не иметь значения, но это единственное, что я вижу, что отличается.
На самом деле простые вещи, которые в ретроспективе кажутся очевидными, но мои знания о Nginx просто были не совсем там. В любом случае, надеюсь, это поможет всем, кто наткнется на это.