tytk
Estoy instalando WordPress en mi servidor Ubuntu con nginx. La instalación fue bastante fluida (después de Instalación de LEMP y Instalación de WordPress tutoriales: me llevó a través de la configuración de mysql, php5-fpm y wordpress), y parece funcionar en su mayoría. Puedo ver la página de administración de WordPress, crear publicaciones de blog e incluso ver esas publicaciones. Pero cuando trato de acceder a la página de inicio de mi blog (por ejemplo, index.php), nginx sirve el archivo como una descarga en lugar de ejecutarlo. Ya probé las configuraciones en Nginx, sirve archivos .php como descargas, en lugar de ejecutarlos sin éxito.
Aquí está mi archivo de servidor virtual:
server {
listen 80;
server_name my.domain.com;
root /my/wordpress/home/dir;
index index.php index.html index.htm;
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location / {
try_files $uri $uri/ /index.php?$args;
rewrite ^/([_0-9a-zA-Z-]+/)?wp-admin$ /$1wp-admin/ redirect;
if (-e $request_filename) {
rewrite ^/([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) /$2 break;
}
rewrite ^/([_0-9a-zA-Z-]+/)?(.*\.php)$ /$2 break;
rewrite ^(.*)$ /index.php break;
}
}
Y nginx.conf:
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 768;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Eliminé las líneas comentadas para mayor claridad. sudo nginx -t
no reporta errores.
¿Cómo puedo hacer que index.php se ejecute en lugar de que se sirva como descarga? Gracias por tu ayuda.
Editar: Parece que fue un problema de almacenamiento en caché del navegador. Intenté eliminar los datos almacenados en caché de las últimas 24 horas, pero no cambió nada. Después de eliminar todo ahora se carga correctamente en lugar de descargarse. También se carga bien en otros navegadores/computadoras.
Para ejecutar WordPress detrás de Nginx, esto funciona para mí:
location / {
# try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?q=$uri&$args;
}
location /wp-content/updraft {
deny all;
}
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
También recomiendo revisar los archivos de muestra del WordPress-Nginx proyecto. En particular, también te puede interesar la globales/restricciones.conf archivo, que endurece un poco su instalación. Si tiene varios sitios de WordPress en el mismo servidor, todos pueden compartir estos archivos de configuración “globales”, lo que facilita su vida como administrador de WordPress.
-
¡Gracias por los enlaces! Marcar su respuesta como correcta es probablemente la más útil. Pude resolver mi problema borrando mis datos de navegación de mi navegador.
– tytk
19 de enero de 2016 a las 6:19
¿Cuál es el propósito de la
rewrite
reglas y elif
. Eso no es estándar y está causando grandes conflictos con sutry_files
regla.– Ricardo Smith
17/01/2016 a las 21:44
Esta es la traducción nginx de la configuración que WordPress me dijo que agregara. ¿Te importa explicar cuál es el conflicto? Nginx coincide con el más largo
location
posible, por lo que cualquier URL que termine en.php
debe ser manejado por el primer bloque. Supongo que eso significa que no se usarán un par de líneas del segundo bloque, pero no veo por qué causaría problemas. Soy nuevo en nginx, así que por favor explique.– tytk
19 de enero de 2016 a las 6:17
El primer problema que veo es
rewrite ^(.*)$ /index.php break;
que, si se activa, evitaría que se ejecute el archivo PHP (verbreak
aquí). El segundo problema es-e $request_filename
que es una forma antigua de implementartry_files
. Un recurso para implementar WordPress ennginx
es aquí.– Ricardo Smith
19 de enero de 2016 a las 8:56
Gracias @RichardSmith!! Su segundo enlace terminó siendo exactamente la configuración que necesitaba y mi configuración multisitio funcionó correctamente. Todos los demás blogs/documentación/publicaciones en foros que había estado leyendo eran de hace años y años… Me alegro de ver que la gente de nginx escribió sus propios procedimientos para wordpress.
– tytk
24 de enero de 2016 a las 7:15