Hace tiempo me rebané los sesos durante unos meses porque uno de mis servidores con wordpress daba un error 500 cada vez que un usuario realizaba una acción. Realmente esa acción, que era tan simple como hacer click en un botón, no revestia complicación alguna.
Después de buscar, sin éxito, en google y en diferentes foros, me puse a depurar la situación, empezando por ver lo que sucedia en WordPress y hasta encontrar cual era el origen del problema.
Problema
Tenemos instalado un servidor con nginx, funcionando perfectamente con un montón de webs configuradas. Viene un cliente y nos pide instalar un WordPress. Hasta aquí algo que pareceria normal. El cliente nos llama que en ciertas situaciones aparece una pantalla amarilla con un Error 500.
Decidimos investigar un poco y vemos que esto sucede siempre que WordPress ejecuta una linea con la instrucción wp_die()
Esta función envia un mensaje al usuario a la vez que añade un error 500 en la cabecera del paquete que devuelve al navegador.
En este punto es cuando nuestro querido nginx envia la página amarilla con el error 500.
Por no acabar ya y rápido (podria poner ya la solución) voy a explicar porque sucede.
Si vamos a la configuración de nginx:
|
1 |
cat /etc/nginx/sites-available/misitio.com.vhost |
Vemos, entre otras lineas similares, esto:
|
1 2 3 4 5 6 7 8 9 |
error_page 500 /error/500.html; error_page 502 /error/502.html; error_page 503 /error/503.html; recursive\_error\_pages on; location = /error/500.html { internal; } |
Estas instrucciones de nginx obligan al servidor web a enviar la página con el Error 500.
Solución
La solución es tan simple que … da igual!
ISPConfig tiene una opción en la configuración de los sites. Cuando entramos en la creación o edición del Site vemos:
Para hacer que WordPress funcione debemos desmarcar la opción Own Error-Documents.
Esta opción desmarcada elimina el código puesto arriba de la configuración de nginx. A partir de entoncesWordPress envia el mensaje al navegador tal y como se esperaba inicialmente.